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

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 ?