[boost] [thread] condition::notify with unlocked mutex

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-12-06 16:19:26

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