Re: [lwip-devel] Granularity of core locking

[Tim Cussins]

Hi Simon,

On Tue, Jun 28, 2016, at 07:52 PM, address@hidden wrote:
> Tim Cussins wrote:
> > (2) I need a solution asap :) Can you suggest a class of "safe places"
> > to flash the lock?
> >
> >    By flash I mean:
> >
> >    UNLOCK_TCPIP_CORE();
> >    LOCK_TCPIP_CORE();
> I'm afraid I can't: you'd need a mechanism to e.g. prevent the pcb 
> you're sending on to be freed from other threads. lwIP just doesn't 
> provide that (yet?).
> 

I take it that's just an /example/ of something that needs fixing, and
that there's a bunch of other things too?

A couple of notable efforts to move away from big locks would be Linux
BKL and Python GIL. Both were/are non-trivial, but represent big leaps
forward for scalability. Most LWIP deployments probably aren't
interested in this, but both multi-core and real-time projects benefit
from finer-grained locking. Real-time applications often sacrifice
raw-throughput for lower bounds on latency.

If I can find some developer time at this end, would you be open to
discussion about:

LWIP_TCPIP_FINE_GRAINED_LOCKING

for LWIP users that are happy to trade the memory (and some throughput)
for better real-time performance?

Cheers,
Tim