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
   WaitForMultipleObjects(...)
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.

1 files changed, 1 insertions, 1 deletions

diff --git a/mysys/my_wincond.c b/mysys/my_wincond.c
index 353b2fced4e..72a8d65bf1f 100644
--- a/mysys/my_wincond.c
+++ b/mysys/my_wincond.c
@@ -126,7 +126,7 @@ int pthread_cond_timedwait(pthread_cond_t *cond, pthread_mutex_t *mutex,
   EnterCriticalSection(&cond->lock_waiting);
   cond->waiting--;
   
-  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