Re: [lwip-users] Reentrancy in LWIP

[Timmy Brolin]

FreeRTOS Info wrote:
> On 29/09/2010 20:59, Timmy Brolin wrote:
>   
>> 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.
>>>       
>
> Very effective at making something thread safe at the expense of making
> it hellishly slow and inefficient - which users *will* complain about.
>   
Why would it be slow?
A big semaphore lock means fewer reschedules compared to the current
mailbox solution in lwip.
The ideal solution may be reentrant code, and only small locks where
absolutely necessary, but that would be a really big undertaking...
And by fast/slow I am only considering the number of clock cycles
required to do the job. A Semaphore lock may have some potential
priority inversion issues, but that is a priority issue, not a
performance issue.

>> 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.
>>     
>
> Just referring to FreeRTOS because that is what I know:  FreeRTOS has
> binary semaphores, mutexes and recursive semaphores (and counting
> semaphores, but that is outside the scope of the conversation).
>
> Binary semaphores are simple empty/full semaphores where a task would
> block if it attempted to obtain it twice.
>
> Mutexes are binary semaphores with the addition of priority inheritance
> (horrible if you have a "real" real time system).
>
> Recursive semaphores are binary semaphores that can be taken multiple
> times.  You have to give it back the same number of times it was taken
> before it becomes available to any other task.  This feature was
> actually added specifically for a TCP/IP stack implementation and is
> very useful when integrating any third party code.
>   
This is what is called a recursive/reentrant mutex/lock according to
wikipedia: http://en.wikipedia.org/wiki/Reentrant_mutex

The difference between a semaphore and a mutex is that a Semaphore can
be used both for mutual exclusion (locking), and for signaling events
between tasks, while a mutex can only be used for mutual exclusion. But
in return, a mutex can have properties such as recursiveness and
priority inversion protection. Features which cannot be implemented in a
sempahore without interfering with the semaphores function as an event
signal between tasks.

/Timmy Brolin
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.  More than 7000 downloads per month.
>
> + http://www.SafeRTOS.com
> Certified by TÜV as meeting the requirements for safety related systems.
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>