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
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/lwip-users
