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