Re: [boost] [thread] semaphore

Subject: Re: [boost] [thread] semaphore
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2013-09-18 16:11:11

El 18/09/2013 8:19, Tim Blechmann escribió:
>> As I understood the reason semaphores were not included in c++11 was
>> because they were too hard to use and the recommendation is to just use
>> condition_variable instead.
>
> i'm not sure about the rationale for not including semaphores, but tbo
> condition_variables are not exactly easy to use, either and i've seen a
> lot of code, which does not use them correctly. also the API is a bit
> crippled, as they do not allow to identify spurious wakeups ...
>
> performance is another point.

Yes, performance is much better if you only need to wake up a thread 
because an event has occurred (like an incoming packet). Some years ago 
I proposed semaphores for the standard:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2043.html#SemaphoreTypes

"Certainly, the semaphore interface can be emulated with a condition and 
a mutex, but this emulation can't be used for important system 
programming tasks, like device driver implementations, signal handling 
or interrupt handlers."

"Condition variables can't be used in interrupt handlers because 
interrupt handlers should never block and thus, they shouldn't acquire 
locks. The post() semaphore operation turns out to be the only 
synchronization operation that can be safely used in an interrupt 
handler. Shared variables protected by locks cannot be safely accessed 
in interrupt handlers."

A bit off-topic: Many embedded operating systems (e.g. NucleusPlus, 
VxWorks, Integrity...) only provide semaphores (and maybe binary 
semaphores/mutexes) natively as the rest of abstractions can be built 
above those (binary semaphores as mutexes, and condition variables 
combining mutexes and semaphores, like the "algorithm 8a" invented by 
Terekhov.

Best,

Ion