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.
Semaphores are ripe for people misusing them. There are good reasons their use isn't encouraged,
would you be willing to share the arguments *why* their use isn't recommended?
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.
this is clearly wrong, but i'd be happy to be proven wrong by numbers or even better: code that i could run for benchmarking. because my numbers show the opposite.
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).
as you can read in the post you quoted, by benchmarks show a factor of 30 or 80 in case of contention.
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.
sorry, but i strongly disagree: i think that boost is the place for high-performance code, that power users can rely on. i don't know how many `power users' have to maintain abstractions for low-level primitives. regarding semaphores, can you please mention one operating system, that does not support them natively?