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. 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. Ralph On Jul 2, 2009, at 12:39 AM, Ceki Gulcu wrote:
Hello,
I am hesitating between the two following styles of synchronization.
First style, with one lengthy synchronization block
synchronize(x) { shortOpA(); shortOpB(); shortOpC(); shortOpD(); longOp(); }
Second style, with shorter but more numerous synchronization blocks
synchronize(a) { shortOpA(); }
synchronize(b) { shortOpB(); }
shortOpC(); // no need for synchronization shortOpD(); // no need for synchronization
synchronize(x) { longOp(); }
Let us assume that longOp() takes about 5 times longer than shortOp_N() to complete. Moreover, all operations are self contained, with no further synchronization (locking) dependencies to external code.
I wonder which style is better. The first style is simpler to understand, because there is just one synchronization block. However, the monitor is held for a longer period. In the second style, there are more locks, so the code may be harder to follow but each lock is held for a shorter period.
Surprisingly enough, tests (with 10 threads) show that performance is slightly better with the first style.
Am I splitting hairs?
-- 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