Re: [boost] [thread] semaphore

Subject: Re: [boost] [thread] semaphore
From: Tim Blechmann (tim_at_[hidden])
Date: 2013-09-19 12:14:21

>> 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?