Boost logo

Boost :

Subject: [boost] [threads] wait() and signal() ?
From: David M. Cotter (me_at_[hidden])
Date: 2009-10-07 00:25:50


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 ?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk