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?