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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2006-12-06 17:12:47

Peter Dimov wrote:
> Yuval Ronen wrote:
>> 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.
> 
> 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
>> 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?
> 
> 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?