lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Reentrancy in LWIP


From: FreeRTOS Info
Subject: Re: [lwip-users] Reentrancy in LWIP
Date: Wed, 29 Sep 2010 21:49:56 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4

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.


> 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.


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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]