I agree with Ralph: try to keep the locks as briefly as possible. <br>Because<br>a) it could improve scalability<br>b) the reason that Joern gives<br>c) if there ever is a need to change it, making synchonized blocks bigger is probably easier than trying to make them smaller<br>
<br>I definitely agree about not penalizing *all* users with fair locks.<br><br>from Java Concurrency In Practice:<br><br>"While shrinking <tt>synchronized</tt> blocks can improve scalability, a <tt>synchronized</tt> block can be <span class="docEmphasis">too</span>
small. - operations that need to be atomic (such updating multiple
variables that participate in an invariant) must be contained in a
single <tt>synchronized</tt> <a name="iddle1367"></a><a name="iddle1808"></a><a name="iddle2469"></a><a name="iddle2730"></a><a name="iddle3073"></a><a name="iddle3103"></a><a name="iddle3146"></a><a name="iddle3148"></a><a name="iddle4348"></a><a name="iddle4350"></a><a name="iddle4434"></a><a name="iddle4473"></a><a name="iddle5059"></a>block. And because the cost of synchronization is nonzero, breaking one <tt>synchronized</tt> block into multiple <tt>synchronized</tt> blocks (correctness permitting) at some point becomes counterproductive in terms of performance.<sup class="docFootnote"><a class="docLink" href="http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html#ch11fn09">[9]</a></sup> The ideal balance is of course platform-dependent, but in practice it makes sense to worry about the size of a <tt>synchronized</tt> block only when you can move "substantial" computation or blocking operations out of it.<br>
<br><sup><a name="ch11fn09">[9]</a></sup> If the JVM performs lock coarsening, it may undo the splitting of <tt>synchronized</tt> blocks anyway."<br><br><a href="http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html">http://book.javanb.com/java-concurrency-in-Practice/ch11lev1sec4.html</a><br>
<br>Maarten<br><br><br><br><div class="gmail_quote">On Thu, Jul 2, 2009 at 4:37 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;">
<div class="im"><br>
<br>
Ralph Goers 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 would recommend the second, 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>
</blockquote>
<br></div>
Agreed.<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;">
I would comment more but my wife is in the hospital for the next few days so I won't have much time until after the weekend.<br>
</blockquote>
<br></div>
My best wishes to your wife.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ralph<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>