Nick Tarleton created LUCENE-5359:
-------------------------------------
Summary: ThreadAffinityDocumentsWriterThreadPool checks
hasQueuedThreads rather than isLocked
Key: LUCENE-5359
URL: https://issues.apache.org/jira/browse/LUCENE-5359
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.6, 4.5, 4.4
Reporter: Nick Tarleton
Priority: Minor
ThreadAffinityDocumentsWriterThreadPool.getAndLock() calls
minContendedThreadState() to get a ThreadState, then checks hasQueuedThreads()
to determine whether to call newThreadState() or lock the returned ThreadState.
It seems to me that it should be checking isLocked() instead; it shouldn't
accept an already-locked ThreadState just because there are no other threads
queued on it. (Alternately, maybe minContendedThreadState() should prefer to
return an unlocked ThreadState, rather than just checking the queue length.)
Empirically, on 4.4.0, when writing an index from 8 threads on an 8-core
machine, with the hasQueuedThreads() call, the CPU is usually not saturated,
and the writing threads spend up to 15% of their time blocked on the
minThreadState.lock() call in getAndLock(); tracing shows that the return value
of minContendedThreadState() is often used when it's locked but has no queued
threads, even though there are <8 active ThreadStates and newThreadState()
would return a fresh one. When changing hasQueuedThreads() to isLocked(), the
CPU is usually saturated and getAndLock() doesn't block.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
