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

Subject: Re: [boost] [threads] wait() and signal() ?
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2009-10-07 13:58:42

On Wed, Oct 7, 2009 at 12:41 PM, Roland Schwarz
<roland.schwarz_at_[hidden]> 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