Re: [boost] [thread] semaphore

Subject: Re: [boost] [thread] semaphore
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-09-19 12:27:32

On Thursday 19 September 2013 11:46:58 Niall Douglas wrote:
> On 18 Sep 2013 at 13:03, Tim Blechmann wrote:
> > >> 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.
> 
> 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.

The fact that some component A is more difficult to use than the other 
component B should not preclude from implementing A, if it provides benefits 
over B. I'm glad the committee agrees with this and ratified atomics along 
with mutexes.

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

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