Re: [boost] [threads] wait() and signal() ?

Subject: Re: [boost] [threads] wait() and signal() ?
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2009-10-07 13:30:41

Stewart, Robert wrote:
> Roland Schwarz wrote:
>> Gottlob Frege wrote:
>>> If boost threads doesn't have a semaphore, we could add one.
>> boost::thread doesn't have a semaphore for a purpose.
>> boost::threads is modelled after the pthreads API, which does not
>> need what you are seeking for. Perhaps you could look up a book
>> on pthreads for an in depth explanation? For short in pthreads API the
>> state and the notification are decoupled, which is a more general
>> aproach.
>>
>> Of course you know it, but it is straight forward to get the
>> equivalent of a semaphore with boost::threads.
> 
> Isn't it reasonable for a library to provide helpful, tested, reusable, and documented functionality?
> 
> I'm not arguing whether semaphores are an appropriate abstraction or whether their presence would encourage programming styles that should be discouraged.  Those are separate questions.  I'm merely arguing that eschewing a feature because it is fairly straightforward given the provided functionality is weak at best.

I'm not sure why the rationale and FAQ sections of the thread library 
docs have been lost with later versions of the thread library, but the 
following was in boost 1.31.0:

10. Why has class semaphore disappeared?

Semaphore was removed as too error prone. The same effect can be 
achieved with greater safety by the combination of a mutex and a 
condition variable. Dijkstra (the semaphore's inventor), Hoare, and 
Brinch Hansen all depreciated semaphores and advocated more structured 
alternatives. In a 1969 letter to Brinch Hansen, Wirth said "semaphores 
... are not suitable for higher level languages." [Andrews-83] 
summarizes typical errors as "omitting a P or a V, or accidentally 
coding a P on one semaphore and a V on on another", forgetting to 
include all references to shared objects in critical sections, and 
confusion caused by using the same primitive for "both condition 
synchronization and mutual exclusion".

Jeff