I agree with Ralph: try to keep the locks as briefly as possible.
Because
a) it could improve scalability
b) the reason that Joern gives
c) if there ever is a need to change it, making synchonized blocks bigger is probably easier than trying to make them smaller

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] 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

Maarten

On Thu, Jul 2, 2009 at 4:37 PM, Ceki Gulcu <ceki@qos.ch> wrote:

Ralph Goers wrote:

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.

Agreed.

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.

My best wishes to your wife.

Ralph

--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://qos.ch/mailman/listinfo/logback-dev