Subject: Re: [boost] [thread] semaphore
From: Tim Blechmann (tim_at_[hidden])
Date: 2013-09-18 06:33:58
>>> 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 ...
>
> Why do you care if a wakeup is spurious? A condition_variable should
> be associated with some condition (the clue is in the name) and so
> when you wake up you re-check the condition.
>
> If the condition is true then you don't need to care whether you woke
> up because notified or you woke up spuriously but the condition
> happened to be true anyway (e.g. the condition was made true by
> another thread but you woke up just before it notified you.)
>
> If you're not checking some predicate then you're using it wrong.
i've seen a lot of code, which is using condition_variables wrongly,
ignoring the condition. not mine, as i usually use semaphores.
also, checking the condition requires you to acquire a lock, which in
many use cases is not necessary. and locks are not free, as they involve
memory barriers and atomic operations. and how many platforms implement
PI mutexes?
condition_variables have their use, but stating that other
synchronization primitives are more error-prone to use is just wrong!
semaphores and win32-style events do have a well-defined semantics,
which is more suited in many use cases. of course, they can be emulated
with cvs, if you don't care about performance