Boost logo

Boost :

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


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