synchronized / cond.wait

[Sean Kelly]

Sergey Gromov wrote:
> Tue, 31 Mar 2009 15:37:33 +0200, Stefan Rohe wrote:
> 
>> could someone explain us this "synchronize" behaviour? We do not understand
>> it.
>>
>> Two Threads.
>> First Thread should wait for a condition. This we do in a
>> synchronized(mutex) block.
>> The second Thread broadcasts then a notify. This also in a synchronized
>> block, synchronizing on the same mutex. This should be impossible!? Does the
>> condition.wait modify the Mutex object so that it after this has another
>> address?
> 
> The whole point of a condition variable is to allow other threads to
> acquire the same mutex while you're waiting.
> 
> What happens is the mutex associated with the conditional variable is
> unlocked the same instant you start waiting on that variable.  When the
> other thread notifies you, the cond var attempts to lock the mutex again
> and therefore waits until the other thread either leaves the critical
> section or starts waiting itself.

Yeah, the idea behind condition variables is that it's rare you'll want 
to simply wake another thread.  You're generally doing so because some 
state has changed that you want the thread to operate on.  On Windows 
you have to separate the synchronized test from the wait call, which 
results in spurious wake-ups since another thread may have operated on 
the state change before the notified thread wakes up and has a chance to 
do so itself.  There's still a remote possibility that a spurious 
wake-up may occur so you don't want to assume your data structure has 
data in it or whatever, but in practice this is very rare.  For example:

//consume
synchronized( mutex )
{
     while( queue.isEmpty() ) // loop to be sure
         cond.wait();
     auto value = queue.pop();
     writefln( value );
}

If it helps, Object.wait() and Object.notify() in Java were built on the 
same model.