Re: [lwip-users] Bug in pbuf.c regarding PBUF_POOL

[Jonathan Larmour]

Christiaan Simons wrote:
> @Jonathan:
>
> > > We have a proven real-time pre-emptive design (even with nested
> > > pre-emptable interrupts) that does not use SYS_LIGHTWEIGHT_PROT but
> uses
> > > the "bottom-half" approach.
> > I would be surprised if it were truly thread-safe given my understanding
> of
> > the current code. Maybe it used to be with different earlier code. But I
> > haven't seen the code for that port.
>
> What we do is truly thread safe,
> since we protect the calls to the _raw-API_.
>
> As Leon said the interrupt top half merely
> wakes a high priority task (bottom half) on eth rx.
>
> This task locks a (uCOS) mutex, copies data from the
> ethernet controller and pushes this into the lwIP stack.

So it calls etharp_ip_input or etharp_arp_input from that task context with 
the mutex still locked?

> After lwIP is done we unlock this mutex.

Do you mean a mutex or a semaphore? The current pbuf.c code only uses a 
semaphore, and therefore cannot prevent priority inversion.

> Other tasks accessing to any lwIP structure
> are allowed when the mutex is available.

So you mean that you lock and unlock a mutex from the application *every 
time* you make a raw API call?

> We completely avoid the lwIP socket or sequential API,
> therefore we don't require the troublesome lwIP
> "protection".

Well, I want the socket and sequential API to be thread safe too, and I 
think that is achievable. You appear to be describing a different more cut 
down scenario.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
------["The best things in life aren't things."]------      Opinions==mine