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. _______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
