<br><br><div class="gmail_quote">On Thu, Jul 2, 2009 at 6:30 PM, Ceki Gulcu <span dir="ltr"><<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Thank you for this link.<div class="im"><br>
<br>
Maarten Bosteels wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree with Ralph: try to keep the locks as briefly as possible.<br>
Because<br>
a) it could improve scalability<br>
</blockquote>
<br></div>
In the general case, yes.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
b) the reason that Joern gives</blockquote></div></blockquote><div><br>oops, I meant: for the reason that *Ralph* gave<br><br>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."<br>
<br>sorry for the confusion.<br><br>Maarten<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
</blockquote>
<br>
<br></div>
The statement that "the longer a lock is held, the more likely<br>
starvation might occur" is only true at a single singularity point<br>
chosen by the JVM. The JVM will measure thread contention per lock. It<br>
will either spin a thread waiting on a monitor or park it at the level<br>
of the OS/kernel. Very short living locks will be spinned by default,<br>
while locks with longer durations will be parked. Thus, there is a<br>
singularity point where the JVM prefer parking over spinning. For<br>
more detail, see Dave Dice's comments in my blog [1]. Here is a<br>
relevant excerpt:<br>
<br>
Regarding Thread.sleep(1) vs sleep(10), sleep times are quantized<br>
differently on various platforms. On some systems sleep(1) will round<br>
up to at least 10 msecs. I'm assuming you're running on a newer linux<br>
kernel (tickless or 1000HZ) or something similar. With a longer sleep<br>
period (10 msecs) it'll almost be the case that the competing threads<br>
will have given up on spinning and blocked in the kernel. When the<br>
lock holder releases the lock it'll select an "heir presumptive" and<br>
unpark that thread. But in your case the dominating thread will try to<br>
reacquire the lock before the wakee manages to become active. With<br>
shorter sleep times it's more likely that the contending threads will<br>
be spinning instead of blocked, in which case they can immediately<br>
pounce on the lock.<br>
<br>
IBM's JDK has a very different time-slicing behavior. At present<br>
time, I consider LBCLASSIC-140 to be an issue with Sun's JVM. However,<br>
cognizant of the fact that Sun is the dominant JVM "vendor", I am<br>
willing to reconsider but only if new evidence can be brought to bear.<br>
<br>
[1] <a href="http://ceki.blogspot.com/2009/06/biased-locking-in-java-se-60.html" target="_blank">http://ceki.blogspot.com/2009/06/biased-locking-in-java-se-60.html</a><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
c) if there ever is a need to change it, making synchonized blocks bigger is probably easier than trying to make them smaller<br>
</blockquote>
<br></div>
Sure.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
I definitely agree about not penalizing *all* users with fair locks.<br>
<br>
from Java Concurrency In Practice:<br>
<br></div>
"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] <<a href="http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html#ch11fn09" target="_blank">http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html#ch11fn09</a>> 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.<div class="im">
<br>
<br>
^[9] If the JVM performs lock coarsening, it may undo the splitting of synchronized blocks anyway."<br>
<br>
<a href="http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html" target="_blank">http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html</a><br>
</div></blockquote>
<br>
Thank you for this link and the quote.<br>
<br>
<br>
As for JVM lock coarsening, I think it will do so if it is the same<br>
lock that is being held and released. AFAIK, the JVM won't/can't<br>
coarsen distinct locks.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maarten<br>
</blockquote><div><div></div><div class="h5">
-- <br>
Ceki Gülcü<br>
Logback: The reliable, generic, fast and flexible logging framework for Java.<br>
<a href="http://logback.qos.ch" target="_blank">http://logback.qos.ch</a><br>
_______________________________________________<br>
logback-dev mailing list<br>
<a href="mailto:logback-dev@qos.ch" target="_blank">logback-dev@qos.ch</a><br>
<a href="http://qos.ch/mailman/listinfo/logback-dev" target="_blank">http://qos.ch/mailman/listinfo/logback-dev</a><br>
</div></div></blockquote></div><br>