HCha/Stockfish
1
0
Fork 0
mirror of https://github.com/HChaZZY/Stockfish.git synced 2025-12-21 09:37:16 +08:00
Code Issues Packages Projects Releases Wiki Activity

Avoid locking/unlocking in a tight loop

Browse Source 
After previous patch if split point master is
waiting for job and "Use Sleeping Threads" is
false (our condition for official releases) then
it will lock/unlock splitPoint mutex in a super
tight loop badly affecting performance.

Rewrite the code to lock only when we are about
to finish. Note that race condition on slavesMask
is anyhow fixed.

No functional change.
This commit is contained in:
Marco Costalba
2013-03-04 08:58:57 +01:00
parent d165d5af91
commit ccad601389
2 changed files with 10 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
src/search.cpp
View File

@@ -1626,13 +1626,8 @@ void Thread::idle_loop() {
assert(!this_sp || (this_sp->masterThread == this && searching));
// If this thread is the master of a split point and all slaves have finished
// their work at this split point, return from the idle loop.
while (!this_sp || this_sp->slavesMask)
while (true)
{
if (this_sp)
this_sp->mutex.unlock();
// If we are not searching, wait for a condition to be signaled instead of
// wasting CPU time polling for work.
while ((!searching && Threads.sleepWhileIdle) || exit)
@@ -1725,8 +1720,16 @@ void Thread::idle_loop() {
sp->mutex.unlock();
}
if(this_sp)
// If this thread is the master of a split point and all slaves have finished
// their work at this split point, return from the idle loop.
if (this_sp && !this_sp->slavesMask)
{
this_sp->mutex.lock();
bool finished = !this_sp->slavesMask; // Retest under lock protection
this_sp->mutex.unlock();
if (finished)
return;
}
}
}