Dear Zeljko, first of all, thanks for your answer! Regarding your suggestion that "The condition variable should be signaled before the lock is unlocked", I have followed the Boost.thread documentation, as well as the "Thread-Safe Queue using Condition Variables" tutorial in my implementation. See e.g. here: http://www.boost.org/doc/libs/1_35_0/doc/html/thread/synchronization.html#th... and here: http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-... In the second code snipped of the synopsis part of the condition_variable documentation, the notification is clearly done after the lock has been destroyed. The lock only exists within the scope. And Anthony writes "By rewriting the function so that the notification comes after the mutex is unlocked, the waiting thread will be able to acquire the mutex without blocking" See also the code in the Boost.circular_buffer examples: <Boost-Root>/libs/circular_buffer/test/bounded_buffer_comparison.cpp : In the "push_front" function: [...] lock.unlock(); m_not_empty.notify_one(); [...] So all these examples unlock the mutex before doing the notification. And I still don't understand why this should not be correct: In order to reach the part where the notification happens, the function must have locked the mutex first (and unlocked it right before the notification). This means that the other threads are either waiting to be notified through the condition variable, or haven't reached that part yet. If they are waiting, I can signal them. If they aren't and have been lucky enough to acquire the lock after my explicit call to unlock(), they need to check the condition itself ("bool go_" in my case). As it has already been set to "true" within the protected/synchronized area, everything is fine and they need no notification. And those threads that have been woken up by the notification need to acquire the lock first. "bool go_" itself is protected through the mutex. Will think about it. Best, Ruediger