Boost logo

Boost :

Subject: Re: [boost] [thread] semaphore
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2013-10-02 12:47:26


On 9/18/2013 3:11 PM, Ion Gaztañaga wrote:
> 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."
>

This rationale seems surely enough to provide them.

Thanks for that.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk