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#Semaphore... "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