[logback-dev] synchronization style?

[Ceki Gulcu]

Thank you for this link.

Maarten Bosteels wrote:
> I agree with Ralph: try to keep the locks as briefly as possible.
> Because
> a) it could improve scalability

In the general case, yes.

> b) the reason that Joern gives


The statement that "the longer a lock is held, the more likely
starvation might occur" is only true at a single singularity point
chosen by the JVM. The JVM will measure thread contention per lock. It
will either spin a thread waiting on a monitor or park it at the level
of the OS/kernel. Very short living locks will be spinned by default,
while locks with longer durations will be parked. Thus, there is a
singularity point where the JVM prefer parking over spinning.  For
more detail, see Dave Dice's comments in my blog [1]. Here is a
relevant excerpt:

   Regarding Thread.sleep(1) vs sleep(10), sleep times are quantized
   differently on various platforms. On some systems sleep(1) will round
   up to at least 10 msecs. I'm assuming you're running on a newer linux
   kernel (tickless or 1000HZ) or something similar. With a longer sleep
   period (10 msecs) it'll almost be the case that the competing threads
   will have given up on spinning and blocked in the kernel. When the
   lock holder releases the lock it'll select an "heir presumptive" and
   unpark that thread. But in your case the dominating thread will try to
   reacquire the lock before the wakee manages to become active. With
   shorter sleep times it's more likely that the contending threads will
   be spinning instead of blocked, in which case they can immediately
   pounce on the lock.

IBM's JDK has a very different time-slicing behavior. At present
time, I consider LBCLASSIC-140 to be an issue with Sun's JVM. However,
cognizant of the fact that Sun is the dominant JVM "vendor", I am
willing to reconsider but only if new evidence can be brought to bear.

[1] http://ceki.blogspot.com/2009/06/biased-locking-in-java-se-60.html

> c) if there ever is a need to change it, making synchonized blocks 
> bigger is probably easier than trying to make them smaller

Sure.

> I definitely agree about not penalizing *all* users with fair locks.
> 
> from Java Concurrency In Practice:
> 
> "While shrinking synchronized blocks can improve scalability, a 
> synchronized block can be too small. - operations that need to be atomic 
> (such updating multiple variables that participate in an invariant) must 
> be contained in a single synchronized block. And because the cost of 
> synchronization is nonzero, breaking one synchronized block into 
> multiple synchronized blocks (correctness permitting) at some point 
> becomes counterproductive in terms of performance.^[9] 
> <http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html#ch11fn09> 
> The ideal balance is of course platform-dependent, but in practice it 
> makes sense to worry about the size of a synchronized block only when 
> you can move "substantial" computation or blocking operations out of it.
> 
> ^[9] If the JVM performs lock coarsening, it may undo the splitting of 
> synchronized blocks anyway."
> 
> http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html

Thank you for this link and the quote.


As for JVM lock coarsening, I think it will do so if it is the same
lock that is being held and released. AFAIK, the JVM won't/can't
coarsen distinct locks.


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