[logback-dev] synchronization style?

[Maarten Bosteels]

On Thu, Jul 2, 2009 at 6:30 PM, Ceki Gulcu <ceki at qos.ch> wrote:

>
> 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
>
>
oops, I meant: for the reason that *Ralph* gave

which was:  "largely because some of the things that are being synchronized
might be able to be converted to constructs that don't require
synchronization. Furthermore, as long as you are holding a lock over such a
wide scope you run the risk of something being inserted into that
synchronized block that does something that raises the possibility of a
deadlock."

sorry for the confusion.

Maarten


>
>>
>
> 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
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-dev/attachments/20090702/aab7de8a/attachment.htm>