Re: [boost] [thread] semaphore

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

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/