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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html