Re: [RFT PATCH 1/2] win32: optimize condition variable implementation

From: Paolo Bonzini <bonzini@gnu.org>
Date: Jun 8, 2010, 16:27 UTC
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