#81 spurious wakeups of wait() on condition variable need to be handled

[Anonymous]

Originally created by: enz
Originally owned by: somebody

None of the cases in Fuego where a condition variable is used to transmit a signal between threads handle spurious wakeups of the wait() function. This affects SgUctSearch and GtpEngine.

So far, this had not shown any effect and I believe that it is platform-dependent whether spurious wakeups can occur, but the C++11 standard (which uses an equivalent thread library as Boost) allows a wait() to return without that there was a call to notify().

The way to fix this is to use an additional boolean flag (for each condition variable) that is set to true before notify() (while the corresponding lock is held) and put the wait() command in a loop that checks the flag. As an example for a correct code, see this fix that I applied recently to my Blokus program Pentobi, which had the same bug:

​http://sourceforge.net/p/pentobi/code/ci/546f45e6e355e2733a03ef3d8b230015a0dd2bfe/

[Patrick Näf]

Original comment by: enz

BTW, this bug could be a possible explanation why the Cygwin build of Fuego by Ben Lamprechts froze when pondering was enabled, which never occured with the MinGW build of Fuego I did a couple of years ago.

It also reminds me of a bug with NeuroGo (which used GtpEngine from Fuego in its last used version). The Cygwin build of NeuroGo in the CGOS engines standard pack froze sometimes after several hundred games (only if compiled with -O3). I could never explain or reproduce this bug on Linux, so a platform-dependent behaviour like spurious wakeups is a possible cause.