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

Subject: Re: [boost] [threads] wait() and signal() ?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-10-07 00:36:00

AMDG

David M. Cotter wrote:
> on the mac the notion of a semaphore is at a slightly higher level 
> than a condition_variable.
>
> but it seems in boost::thread we must use the actual condition_variable.
>
> on the mac, with a semaphore, the value can be pre-set to signal, so 
> that the next wait() is passed right thru, since the signal was sent 
> ahead of time.
>
> eg: you could do this:
>
> Semaphore        sem;    //    newly initialized semaphore, brand new, 
> never waited upon
>
> sem.signal();        //     you can pre-set the signal!
>
> // later in the code
> sem.wait();        //    no wait, since signal was already sent
>
> //    and later still
> sem.wait();        //     now we wait
>
> in fact, actually, the way it actually happens on the mac is that a 
> newly initialized semaphore comes IN WITH the semaphore pre-signaled.  
> so you actually have to call wait() immediately to eat that signal.
>
> i've got lots of code that does this:
>
> Semaphore        sem;
>
> sem.wait();    //    eat the first signal
>
> i thought that was normal.  trouble is,i've got lots of code that does 
> NOT eat that first signal, depending on the first wait call to be 
> passed thru immediately.  this is the code that now breaks.
>
> in converting to boost::thread, there doesn't seem to be a way to 
> pre-set the signal.  or to reset the state of a semaphore from an 
> unknown state to a known state, eg this code:
>
> sem.signal();
> sem.signal();
> sem.wait();
>
> that guarantees that the next wait will actually wait, regardless of 
> the state of the sem before hand.
>
> how can i do this with boost::thread ?

A condition variable doesn't have state.  If you call wait, you
will always block until another thread calls notify_one or notify_all.
notify_one and notify_all have no effect if no threads are waiting.

In Christ,
Steven Watanabe