Re: [lwip-users] Reentrancy in LWIP

[Timmy Brolin]

Bill Auerbach wrote:
> 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.
Actually, what you are talking about is probably more appropriately
called a mutex, not a semaphore.
The way I understand it, a semaphore cannot be associated to a task, so
if a task requests a binary semaphore twice, it will block in the second
request.
A mutex on the other hand is associated to a task when requested, and
can be requested/released recursively without problems.
Not all operating systems have recursive mutexes, so for portability it
is probably better to use binary semaphores.

>   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 simplicity of implementing the lwip timer system the way you
describe has already been discussed as one of several strong reasons for
using this kind of lock.
The current mailbox timeout based lwip timer system is a bit clumsy.

Timmy Brolin

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