Hello. The Boost CV class forces that a mutex would be locked when calling wait(), but not when calling notify(). This seems a bit strange to me. As far as my understanding of CVs goes (and experience with them), locking when notifying is just as "makes sense" as locking when waiting. When waiting, we check the predicate, and when notifying, we change that predicate. And it is only obvious that all reads and writes to the shared-among-threads predicate should be locked. Shouldn't it? I might be just be barking at the wrong tree here, because I realize that Boost.Thread follows the POSIX standard to a great extent, and POSIX doesn't require locking when notifying. However, even if we want to provide this option, it seems to me that it's definitely the rare, rather than the common case. Providing an interface that will ensure for notifying, locking the *same* mutex as when waiting, will greatly reduce bugs (and as a side effect, I think it will also greatly improve CV performance on Windows). What I'm suggesting is that the condition constructor would accept a mutex reference and store it. The Lock& argument to the wait() method will be removed, as there's already a reference to the mutex. It might also be useful to templatize the condition class for Mutex type: template <class Mutex> class condition; although I'm not sure about that. Does all that make sense? Yuval