RE: [lwip-users] Reentrancy in LWIP

[Bill Auerbach]

9 or 10 years ago I worked with a non-reentrant stack which was made "RTOS
compatible" by using this method.  There simply was a macro at function
entry to lock a semaphore and one at exit to release it.  It was one liner
of RTOS-specific code which was easily removed by using an empty macro.
Every function that could be called from the application had this addition.
It was no problem when one function with the addition calls another.  In
fact most RTOSes are very efficient when a thread is locking a semaphore
that it already owns.  All functions have to exit at the bottom which meant
a few functions had gotos to the bottom where mid-function returns existed.
(The end macro could have the label included but the code I was using added
it explicitly).  What was not done was error checking on the RTOS function
return values but I don't think this is necessary - lwip_init could lock and
unlock to check that the locking is available and doesn't return any errors.

This global locking worked really well for preemptive multitasking including
allowing the timer task to call into the stack for the timing-based calls.
The only down-side is if you miss adding this to a function that needs it,
you might create an intermittent problem.

Bill

>-----Original Message-----
>From: address@hidden
>[mailto:address@hidden On
>Behalf Of Timmy Brolin
>Sent: Tuesday, September 28, 2010 4:12 PM
>To: Mailing list for lwIP users
>Subject: Re: [lwip-users] Reentrancy in LWIP
>
>Today the device drivers and application threads exchange information
>with the lwip thread using mailboxes. This avoids any reentrancy issues.
>
>There is a task registered on savannah, where it has been suggested that
>a simple global semaphore lock for the entire lwip stack probably would
>be better (higher performance due to less rescheduling, and smaller ROM
>footprint).
>There is some experimental code in place for this lock, but nothing
>stable.
>
>Timmy Brolin
>
>
>Kieran Mansley wrote:
>> On Tue, 2010-09-28 at 19:04 +0530, Chandran, Smitha wrote:
>>
>>> I have been going through the lwip source code and I have seen
>instances of methods which update data into variables and return them...
>>> My intention is to interface lwip to both an ethernet device as well
>as a usb-wifi device...
>>> So was wondering if such non-rentrant code could lead to issues.
>>>
>>
>> Yes, it would, but you shouldn't write your code that way: lwIP core
>> should only be accessed by a single thread.  The normal method to
>> achieve this is to have all lwIP processing done by a single thread
>and
>> the device drivers (e.g. for Ethernet or USB) pass packets to this
>> thread for processing.  This isn't an just an issue where you have
>more
>> than one device driver either, it applies to protecting lwIP from
>> concurrent access by application threads and device driver context
>too.
>>
>> Kieran
>>
>>
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users