From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-12-06 17:12:47
Peter Dimov wrote:
> Yuval Ronen wrote:
>> 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.
> It isn't strange since notify is typically not called with the mutex locked.
> This would cause the awakened thread to immediately be put back to sleep to
> wait for the mutex.
Yes, but what's the harm in that? The notify simply change the state of
the thread from "waiting on a CV" to "waiting on a mutex". I'm no
operating system expert, but I guess it can be done with a flip of a
flag (or two) inside the kernel. After that we continue normally. Seems
reasonable 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
>> 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?
> It should.
So I understand that it's your opinion that the benefits of having an
interface that emphasizes locking both on wait and on notify - of the
same mutex, as it should - aren't worth it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk