From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-12-06 16:19:26
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>
although I'm not sure about that.
Does all that make sense?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk