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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-12-07 14:26:21

Yuval Ronen wrote:
> ... And it is only obvious that all reads and writes to the 
> shared-among-threads predicate should be locked. Shouldn't it?

Of course, the predicate access needs to be locked. But there is no
requirement for the signaling part, since this does not access the 
predicate.

> ... also greatly improve CV 
> performance on Windows).

Do you mean: Requirement to hold the lock while signaling will improve 
speed ?

If so I might tell you, that the intent of not requiring to hold the 
mutex while signaling is expected to improve speed. Butenhof 
(Programming with Posix Threads) says:

   "Although you must have the associated mutex locked to wait on a 
condition variable, you can signal (or broadcast) a condition variable 
with the associated mutex unlocked if that is more convenient. The 
advantage of doing so is that, on many systems, this may be more 
efficient. When a waiting thread awakens, it must first lock the mutex. 
If the thread awakens while a signaling thread holds the mutex, then the 
awakened thread must immediately block on the mutex - you've gone 
through two context switches to get back where you started. (There is an 
optimization, which I've called wait morphing, that moves a thread 
directly from the condition variable wait queue to the mutex wait queue 
in this case, without a context switch, when the mutex is locked. This 
optimization can produce a substantial performance benefit for many 
applications.)
Weighing on the other side is the fact that, if the mutex is not locked, 
any thread (not only the one being awakened) can lock the mutex prior to 
the thread being awakened. This race is one source of intercepted 
wakeups. A lower-priority thread, for example, might lock the mutex 
while another thread was about to awaken a very high-priority thread, 
delaying scheduling of the high-priority thread. If the mutex remains 
locked while signaling, this cannot happen - the high-priority waiter 
will be placed before the lower-priority waiter onr the mutex and will 
be scheduled first."

I might be wrong, but AFAIK "wait morphing" generally cannot be done in 
a user-space library, it needs to intimately interact with the scheduler.

> Providing an interface that will ensure for 
> notifying, locking the *same* mutex as when waiting, ...
...
> 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:

What would this be of help for? Changing a predicate needs locking the 
mutex, not signaling it. If you mean that the signal function internally 
first should lock the mutex, signal and then unlock it, this would make 
things even worse (And is quite different from the case Butenhof 
addresses in the above citation, since this will be of no help in the 
priority case.)

Also putting the mutex into the condition ctor would make construction 
unnecessary complicated. E.g. how would you do in the following (quite 
common) case:

class foo {

mutex m;
condition c;
};

Btw.: I highly recommend reading Butenhofs book, it not only covers 
pthreads, but will help getting a better general understanding of 
threading too.

Regards,
Roland