On 19 Sep 2013 at 20:27, Andrey Semashev wrote:
Semaphores are ripe for people misusing them.
...and blessing for those who manage to use them right. The same could be said about pretty much any component.
Of course, but I see more frequent race conditions in semaphore using code than other systems. For example, ASIO has a race condition on IOCP writes if you allow its completion port semaphore to be higher than one. Semaphores are the best tool for a limited set of use cases, but I'd use them as a last resort.
There are good reasons their use isn't encouraged, especially as it's extremely easy to roll your own with an atomic, a mutex and condvar which will be just as fast as any native implementation. I also might add that your figures might be good for an uncontended semaphore, but I'd bet you a top dollar semaphores perform terribly when contended whereas CVs will be less pathological (agreed this depends on the CPU in question).
Do you have numbers to prove your distrust for semaphores? Because my experience is quite different, and my use cases implied heavy contention, where semaphore and atomics allowed to avoid excessive context switches. My experience is mostly with Linux, though.
My main item of distrust is debugging race conditions caused by their use. Performance can be very good, but no better than alternatives in most cases. If by contention you mean the semaphore has a permit count of 20 and the average threads in flow is 25, then that's not what I mean by contention. By contention I mean a permit count of 1 and 1000 threads very rapidly getting through the protected code. In this situation a semaphore is no faster than a mutex in my experience.
I would also be far more concerned with correctness than performance in any threading primitive. If the power users really need performance, they'll roll their own. Boost is no place for such brittle threading primitives with many caveats and/or architecture specific assumptions.
I disagree. Designing and implementing such commonly used primitive as a semaphore or event, with proper porting to different platforms and testing, is a huge help for developers. Let alone potentially making it standard, if the design proves right.
As I mentioned, I'm soft for standardised win32 style events and would just love one present in the C standard. Here's a C11 proposed notifier object: https://github.com/ned14/ISO_POSIX_standards_stuff/tree/master/pthread s%20Notifer%20Object. As I mentioned, I got no interest from libc maintainers to add it, therefore POSIX couldn't get interested. A shame. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/