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 synchronizedblock 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 Maarten On Thu, Jul 2, 2009 at 4:37 PM, Ceki Gulcu <[email protected]> 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 > [email protected] > http://qos.ch/mailman/listinfo/logback-dev >
_______________________________________________ logback-dev mailing list [email protected] http://qos.ch/mailman/listinfo/logback-dev
