mirror of
https://github.com/HChaZZY/Stockfish.git
synced 2025-12-20 00:56:39 +08:00
Avoid locking/unlocking in a tight loop
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:
@@ -312,7 +312,6 @@ void Thread::split(Position& pos, Stack* ss, Value alpha, Value beta, Value* bes
|
||||
sp.mutex.unlock();
|
||||
Threads.mutex.unlock();
|
||||
|
||||
// Calling idle_loop with sp.mutex locked
|
||||
Thread::idle_loop(); // Force a call to base class idle_loop()
|
||||
|
||||
// In helpful master concept a master can help only a sub-tree of its split
|
||||
@@ -323,10 +322,6 @@ void Thread::split(Position& pos, Stack* ss, Value alpha, Value beta, Value* bes
|
||||
// We have returned from the idle loop, which means that all threads are
|
||||
// finished. Note that setting 'searching' and decreasing splitPointsSize is
|
||||
// done under lock protection to avoid a race with Thread::is_available_to().
|
||||
// idle_loop returns with sp.mutex locked but we must unlock it inorder to
|
||||
// lock Threads.mutex without conflicting with check_time() (threads holding
|
||||
// multiple locks must always acquired them in the same order to avoid deadlocks)
|
||||
sp.mutex.unlock();
|
||||
Threads.mutex.lock();
|
||||
sp.mutex.lock();
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user