[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] Granularity of core locking
From: |
Tim Cussins |
Subject: |
Re: [lwip-devel] Granularity of core locking |
Date: |
Wed, 29 Jun 2016 10:00:29 +0100 |
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