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