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.
- The condition variable implementation "lost" a signal to
WaitOnSingleObject when a semaphore was released.
- The signal could be consumed by a new call to pthread_cond_wait
before all waiting threads had awoken.
- The new implementation of pthread_cond_* uses events
instead of semaphores. It also uses an extra lock to protect entry
into new cond wait before the broadcast has finished.
- Use same precision (milliseconds) for all time functions
used when calculating time for pthread_cond_timedwait
- Use 'GetSystemTimeAsFileTime' for both start and curr time
