Re: [lwip-devel] core/timers.c with NO_SYS?

[Leon Woestenberg]

Hello,

On Sun, Jun 12, 2011 at 8:29 PM, Kieran Mansley <address@hidden> wrote:
>
> That sounds to me like we've got what Leon wanted, albeit with some code such 
> as sys_now that is poorly named (for a good reason of backwards 
> compatibility).  If this distinction can be clarified, either with code 
> changes or documentation, then
I'd be very happy to see that.
>
Thanks for concluding, agreed.

> On the general point of avoiding sys_arch code in the core, I'm agreed that 
> this is a good principle.  We would need to have a strong justification to 
> start introducing sys_arch code there.
>
What we have is sys_arch code sprinkled through out:

mem.c
memp.c
netif.c
pbuf.c

This is 95% taking mutex locks on data structures or even pieces of
code, without even the idea what data is actually protected against
concurrent access.

However, this makes the pretention that that part of the stack is
multithreading safe, which I'm almost sure it is not (but I cannot
prove it).

I'ld rather see the sys_arch layer implement its own API that wraps
all core function calls in a few mutexes.

We have this bad design pattern now:

sys_arch_function() {
  ...
  core_function();
  ...
}

core_function {
  ...
  sys arch lock
  ...
  sys arch unlock
  ...
}

which I rather see converted to:

sys_arch_function() {
  lock;
  core_function()
  unlock;
}

As the core API is fully non-blocking / non-sleeping, there is no
reason to take fine-grained locks.

Regards,
-- 
Leon