From: Paolo Bonzini <bonzini@gnu.org>
Date: Tue, 08 Jun 2010 16:27:08 GMT
Subject: Re: [RFT PATCH 1/2] win32: optimize condition variable implementation
Message-ID: <4C0E6F5C.6050809@gnu.org>
In-Reply-To: <4C0E6CC2.1080605@viscovery.net>

On 06/08/2010 06:16 PM, Johannes Sixt wrote:
> This is not correct. While it is not possible that two threads increment
> waiters at the same time due to the external mutex, it is still possible
> that on thread increments, and a different one decrements. You lost all
> provisions to avoid that.

Actually, the patch is only relying more widely on the preexisting 
assumptions of the code:

/*
  * IMPORTANT: This implementation requires that pthread_cond_signal
  * is called while the mutex is held that is used in the corresponding
  * pthread_cond_wait calls!
  */

/*
  * IMPORTANT: This implementation requires that pthread_cond_broadcast
  * is called while the mutex is held that is used in the corresponding
  * pthread_cond_wait calls!
  */

During the locked decrements, but then the external mutex is held by the 
thread executing pthread_cond_signal/pthread_cond_broadcast, so that 
section of the code is still protected against increments.

> Furthermore, waiters_lock not only protects waiters, but also the
> combined state of waiters and was_broadcast.

Concurrent pthread_cond_broadcast are protected by the external mutex, 
and was_broadcast is similarly protected against increments of waiters.

Futhermore, access to was_broadcast is serialized between 
pthread_cond_wait and pthread_cond_broadcast through the semaphore and 
the event.  was_broadcast may change from 0 to 1 while pthread_cond_wait 
is not holding the external mutex, but then pthread_cond_wait is 
sleeping on the semaphore or will go to sleep very soon.  And it can 
change from 1 to 0 only after pthread_cond_wait has signaled the event, 
which means pthread_cond_wait will be waiting to reacquire the external 
mutex.

Paolo