adaptive spinning: fall back to sleep / block?
Andriy Gapon <[email protected]>
| Newsgroups | gmane.os.freebsd.architechture |
|---|---|
| Message-ID | <[email protected]> |
Until I recently looked at the actual code I was under an impression that the adaptive spinning is bounded and that after some time / number of spins a thread would go to a sleep queue or a turnstile. But it looks that the spinning is actually unbounded as long as its conditions hold (some other thread owns the lock and that thread is running, the owner could be changing too). In my opinion, it does not make sense to spin for "too long". If there was not an opportunity to take a lock quickly, then it's better to block waiting for it rather than keep occupying a processor. For instance, the spinning can prevent another runnable thread from running. I think that if a lock is heavily contended or its hold times are on the longer side (or both), then the adaptive spinning can make the system behavior (performance, responsiveness) worse. Finally, I was under an impression that 'adaptive' meant some heuristic on whether and when to do the spinning. _A lock owner is running_ seems to be too simple to qualify as 'adaptive'. As an example, this looks like a relatively sophisticated implementation of the "adaptiveness": http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/runtime/objectMonitor.cpp#l1919 But, JIMHO, simply having a hard limit on the spin count would be better than what we have now. P.S. This is not an area that I know well, so my confusion and ideas may be absurd. On the other hand, I could not find any justification for the current unbounded "adaptive" spinning. -- Andriy Gapon _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "[email protected]"