Maarten Bosteels wrote:
Hello all,
While I have not tested any of the scenario's described above, I think the remarks from Ralph make a lot of sense. And I am also interested in knowing the impact on throughput of using fair locks.
When the fairness of non-fair locks has changed so drastically with 1.6, I would guess that more people would suffer from it, no ? Logback is certainly not the only code using non-fair locks. I googled a bit about "java 1.6 starvation" but nothing really alarming came up.
regards, Maarten
I just googled for "java synchronized fairness" and the first two links that came up were http://tutorials.jenkov.com/java-concurrency/starvation-and-fairness.html and http://tutorials.jenkov.com/java-concurrency/locks.html I've also found the following PDF: http://home.comcast.net/~pjbishop/Dave/MustangSync.pdf See page 12: Fairness vs throughput
Optimized for system-wide throughput at the expensive of short-term thread-specific fairness Succession policy: try to wake recently run threads Improved $ and TLB utilization
TLB means http://en.wikipedia.org/wiki/Translation_lookaside_buffer This post from the author of the PDF is quite technical but on the topic: http://blogs.sun.com/dave/entry/biased_locking_in_hotspot So it is a performance enhancement as I guessed. I highly doubt that this will be reverted. I'd more or less expect the other implementations to follow. After all, this is *not* a bug at all. This behavior, while obviously being extreme, is absolutely in conformance with all documentation. So if it doesn't breach the documentation contract and means a worthwhile performance increase: why switch it back? Regards, Joern.