[logback-dev] [JIRA] Commented: (LBCORE-97) Starvation on AppenderBase.doAppend

[Ceki Gulcu]

Joern Huxhorn wrote:
> 
> 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?

Given the highly technical nature of the subject, it is possible that
the change went through without anyone noticing its negative
effects. Unfortunately, such wide-ranging mistakes happen all the
time.

As for the argument about no guarantees offered about fairness, while
true in letter, it is invalid in spirit. The argument is too
punctilious and formalistic. Any developer reading the docs will
naturally assume that while there are no guarantees, the
synchronization mechanism will not actively impede fairness. In JDK
1.6, the scheduler will systematically favor the thread last holding
the lock so that it will always get access to the synchronized
resource. Sun calls it biased locking.

Biased locking, as introduced in JDK 1.6, will effect thousands of
unsuspecting applications. The fact that the bias is intentional does
not make it less damaging. It's still a bug.

Having said that, I also agree that Sun will not revert to the
previous locking behavior anytime soon. I intend to complain about
this change as loudly as I can. In the mean time, we'll have to
accommodate JDK 1.6 by adopting fair locking primitives as provided by
java.util.concurrent.

> Regards,
> Joern.

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch