Boost logo

Boost :

Subject: Re: [boost] [thread] semaphore
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-09-20 12:11:58

On 19 Sep 2013 at 22:49, Andrey Semashev wrote:

> > Semaphores are the best tool for a limited set of use cases, but I'd
> > use them as a last resort.
> Right, semaphores are a tool with its use cases. It should be used
> carefully, but just as well as all threading primitives. Believe it or not,
> I spend much more time debugging incorrect use of mutexes and CVs than
> semaphores.

I think we might actually be more in agreement than not :)

> > If by contention you mean the semaphore has a permit count of 20 and
> > the average threads in flow is 25, then that's not what I mean by
> > contention.
> No, it's more like a few hundred of threads in different processes
> synchronizing on a single lock-free queue.

As a "lock contention brake" wrapping other locking mechanisms by
gating out contention before reaching the critical code, something
like a semaphore can be very useful. In that situation any race
conditions are simply inefficiency, not incorrectness.

BTW I'm sure you'll agree that we're all looking forward to
widespread transactional memory. On the limited amount of it I've
worked with, there were far fewer threading problems. I think it
matches the mental map people have of memory better, so you get less
problematic code, but equally it could be selection bias due to the
threading experienced perhaps embracing writing in TM sooner than


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at