Since you’re here...

... we have a small favour to ask. More people, like you, are reading and supporting our blog: "Chess Engines Diary". And unlike many other sites and blogs, we made the choice to keep our articles open for all, regardless of where they live or what they can afford to pay.

We hope you will consider supporting us today. We need your support to continue to exist, because good entries are more and more work time. Every reader contribution, however big or small, is so valuable. Support "Chess Engines Diary" even a small amount– and it only takes a minute. Thank you.

============================== My email: jotes@go2.pl



Stockfish 17062122 - new version!

Stockfish, chess engine UCI

Leader rating list JCER = 3372
๐Ÿ”ฌ Author: Joost VandeVondele

More:
Timestamp: 1498077478 

Fix four data races. 

the nodes, tbHits, rootDepth and lastInfoTime variables are read by multiple threads, but not declared atomic, leading to data races as found by -fsanitize=thread. This patch fixes this issue. It is based on top of the CI-threading branch (PR #1129), and should fix the corresponding CI error messages. 

The patch passed an STC check for no regression: 

http://tests.stockfishchess.org/tests/view/5925d5590ebc59035df34b9f 
LLR: 2.96 (-2.94,2.94) [-3.00,1.00] 
Total: 169597 W: 29938 L: 30066 D: 109593 

Whereas rootDepth and lastInfoTime are not performance critical, nodes and tbHits are. Indeed, an earlier version using relaxed atomic updates on the latter two variables failed STC testing (http://tests.stockfishchess.org/tests/view/592001700ebc59035df34924), which can be shown to be due to x86-32 (http://tests.stockfishchess.org/tests/view/592330ac0ebc59035df34a89). Indeed, the latter have no instruction to atomically update a 64bit variable. The proposed solution thus uses a variable in Position that is accessed only by one thread, which is copied every few thousand nodes to the shared variable in Thread. 

No functional change. 

Closes #1130 
Closes #1129 


Comments