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/