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 ?