I think the semaphores are a good idea. When you work with low latency concurrent data structures, the mutex and condition variables are very slow. Even the spinlocks done with atomic variables are slow. In my library [countertree + suballocator] the suballocator spends 0.74 seconds in allocate 50000000 elements, the same code with a spinlock spends 3.5 seconds. I am agree with the critics to the standard, but my main critics to the standard is that many times they forget the "common people" language. I see when explain to my students. I must translate from the "expert" language to the "common people" language, and then they understand the use and functionality of the things. If they have problems for to understand, they will have problems when use it. I think this is a main part of the problems using the semaphores. I know it is not easy ( I know by experience), but spend time in this , save time of a lot of people. 2013/9/18 Tim Blechmann <tim@klingt.org>
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?
Don't semaphores involve memory barriers and/or atomics too? POSIX semaphores do.
(N.B. I'm not disputing that semaphores have less overhead than CVs.)
they do, but much less: according to some micro-benchmarks with much contention, dispatch semaphores on osx are about 80 times faster than CVs, while posix semaphores on linux are about 30 times faster.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost