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