From 22e40c8c107500931e775ca72da74f4ac8df0620 Mon Sep 17 00:00:00 2001 From: Marco Costalba Date: Sat, 31 Dec 2011 15:27:14 +0100 Subject: [PATCH] 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 --- src/lock.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/lock.h b/src/lock.h index 3b3de1ac..0af1443d 100644 --- a/src/lock.h +++ b/src/lock.h @@ -75,8 +75,8 @@ typedef HANDLE WaitCondition; # define cond_init(x) { *x = CreateEvent(0, FALSE, FALSE, 0); } # define cond_destroy(x) CloseHandle(*x) # define cond_signal(x) SetEvent(*x) -# define cond_wait(x,y) { lock_release(y); WaitForSingleObject(*x, INFINITE); lock_grab(y); } -# define cond_timedwait(x,y,z) { lock_release(y); WaitForSingleObject(*x,z); lock_grab(y); } +# define cond_wait(x,y) { ResetEvent(*x); lock_release(y); WaitForSingleObject(*x, INFINITE); lock_grab(y); } +# define cond_timedwait(x,y,z) { ResetEvent(*x); lock_release(y); WaitForSingleObject(*x,z); lock_grab(y); } #endif -- 2.39.2