Re: [boost] [thread] semaphore

Subject: Re: [boost] [thread] semaphore
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-09-19 13:24:20

On 19 Sep 2013 at 20:27, Andrey Semashev wrote:

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

Of course, but I see more frequent race conditions in semaphore using 
code than other systems. For example, ASIO has a race condition on 
IOCP writes if you allow its completion port semaphore to be higher 
than one.

Semaphores are the best tool for a limited set of use cases, but I'd 
use them as a last resort.

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

My main item of distrust is debugging race conditions caused by their 
use. Performance can be very good, but no better than alternatives in 
most cases.

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.

By contention I mean a permit count of 1 and 1000 threads very 
rapidly getting through the protected code. In this situation a 
semaphore is no faster than a mutex in my experience.

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

As I mentioned, I'm soft for standardised win32 style events and 
would just love one present in the C standard. Here's a C11 proposed 
notifier object: 
https://github.com/ned14/ISO_POSIX_standards_stuff/tree/master/pthread
s%20Notifer%20Object. As I mentioned, I got no interest from libc 
maintainers to add it, therefore POSIX couldn't get interested. A 
shame.

Niall

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