Boost logo

Boost :

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


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

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