On Wed, Oct 7, 2009 at 12:41 PM, Roland Schwarz <roland.schwarz@chello.at> 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,
only to a certain point, I would say.
which does not need what you are seeking for. Perhaps you could look up a book on pthreads for an in depth explanation?
I'm quite familiar with pthreads. (Even made a small contribution to pthreads-win32! Not that that actually proves familiarity, I suppose.) Also note that most POSIX implementations *do* have semaphores, whether they are formally part of pthreads or not. Often, of course, this is because the sema is at a different level then pthreads (ie callable from interrupts, etc. Not that I'm suggesting we should attempt something like that!)
For short in pthreads API the state and the notification are decoupled, which is a more general aproach.
Definitely. And usually the better approach. But being more general just means more possible uses. It doesn't mean that a more specific construct isn't better in a certain case. The question is whether that case is common enough. Personally, I don't like semas much - the descriptions and terminology, in particular, tend to make them confusing and error-prone. But maybe we could rectify that. For a binary semaphore (ie Windows 'event') they can at times be useful. ie for call_once() implementations, once the initial mutual exclusion (ie the 'once' part) has been done, there is no need to re-grab the mutex - all the 'waiters' really do is wait on the "done" event. And then they can ALL go forward. In the current boost impl, each waiter wakes up, grabs the mutex, then immediately lets it go again. A binary semaphore would work better here. (In fact, depending on the internals, it may be that ALL the waiters wake up, race for the mutex, all but one go back to waiting, 'winner' grabs mutex and immediately frees it, repeat until waiters == 0...) But maybe that's the only good example, and it is burried inside boost::threads already. The original boost rationale (posted further down by Jeff Flinn) maybe makes more sense. Although I don't agree with all of it. (For example "forgetting to include all references to shared objects in critical sections" is a common error for all threading, not just semaphores.) Lastly, also note that most unix systems have things like select() making semaphores less useful, whereas Windows might use Events in those cases. Anyhow, I'm not actually arguing that strongly for semaphores. It was just a suggestion. In 15 years of threading, I think I've only used a counting semaphore once. Events moreso, but mostly because I was stuck on Windows.
Regards, Roland
Tony