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?