Fix cond_signal() semantics when using OLD_LOCKS
authorMarco Costalba <mcostalba@gmail.com>
Sat, 31 Dec 2011 14:27:14 +0000 (15:27 +0100)
committerMarco Costalba <mcostalba@gmail.com>
Sat, 31 Dec 2011 14:40:12 +0000 (15:40 +0100)
commit22e40c8c107500931e775ca72da74f4ac8df0620
tree99bf37bed85da43f8b219cf4db062d12baac0bcd
parente9296d694c72c2378b71ad29cfff2f2c7b45bb0c
Fix cond_signal() semantics when using OLD_LOCKS

In Windows when OLD_LOCKS is defined we use SetEvent() to mimic
the semantic of the POSIX pthread_cond_signal().

Unfortunatly there is not a direct mapping because with SetEvent()
the state of an event object remains signaled until it is set
explicitly to the nonsignaled state or until a single waiting thread
has been released. Instead in case of pthread_cond_signal(), if there
are no waiting threads it has no effect. What we may want is something
like PulseEvent() instead of SetEvent(). Unfortunatly it is documented
by Mcrosoft as 'unreliable' due to spurious wakes up that could
filter out the signal resetting. So we opt to reset manually any
pending signaled state before to go to sleep.

This fixes the strange misbehaves during 'stockfish bench'
when using OLD_LOCKS under Windows.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
src/lock.h