#At file:///Users/thek/Development/mysql-5.1-bugteam/ based on revid:kristofer.pettersson@stripped
3144 Kristofer Pettersson 2009-10-01
Bug#47768 pthread_cond_timedwait() is broken on windows
The pthread_cond_wait implementations for windows might
dead lock in some rare circumstances.
1) One thread (I) enter a timed wait and at a point in
time ends up after mutex unlock and before
2) Another thread (II) enters pthread_cond_broadcast.
Grabs the mutex and discovers one waiter. It set
the broadcast event and closes the broadcast gate
then unlocks the mutex.
3) A third thread (III) issues a pthread_cond_signal.
It grabs the mutex, discovers one waiter, sets the
signal event then unlock the mutex.
4) The first threads (I) enters WaitForMultipleObjects
and finds out that the signal object is in a
signalled state and exits the wait.
5) Thread (I) grabs the mutex and checks result status.
The number of waiters is decreased and becomes equal
to 0. The event returned was a signal event so the
broadcast gate isn't opened. The mutex is released.
6) Thread (II) issues a new broadcast. The mutex is
acquired but the number of waiters are 0 hence
the broadcast gate remains closed.
7) Thread (I) enters the wait again but is blocked by
the broadcast gate.
This fix resolves the above issue by always resetting
broadcast gate when there are no more waiters in th queue.
* Always reset the broadcast gate if there are no more waiters left.
=== modified file 'mysys/my_wincond.c'
--- a/mysys/my_wincond.c 2007-05-10 09:59:39 +0000
+++ b/mysys/my_wincond.c 2009-10-01 17:33:06 +0000
@@ -120,13 +120,12 @@ int pthread_cond_timedwait(pthread_cond_
result= WaitForMultipleObjects(2, cond->events, FALSE, timeout);
- if (cond->waiting == 0 && result == (WAIT_OBJECT_0+BROADCAST))
+ if (cond->waiting == 0)
We're the last waiter to be notified or to stop waiting, so