|
This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Artima Forums.
Message:
I'd lean towards minimizing synchronized code
Posted by Bill Venners on 16 Jul 1998, 1:36 AM
> Some time ago I think I read an article (paper magazine) that dealt with
> syncronisation. It seems to me that this article advocated putting the
> "syncronized" keyword not on the critical sections themselfs, but instead
> on methods. The idea was that the syncronisation overhead made this
> a faster approach.
> Note that the example had _several_ critical sections in each method. > So, my question then: Is the idea of syncronising methods instead of critical
> sections just unneccessary sub optimising? Or does it have merit in the case
> of several critical sections in one method? Interesting. I've never heard that one before. All I've heard
is comparisons of the costs of synchronized versus
non-synchronized method invocations. I can't think of what
would cause the extra performance hit to synchronize on a
block versus a method call either. Nonetheless, I think I will pull out my stock answer to
performance questions such as this one: Avoid premature
optimization. I think I'll write this up somewhere and just
refer to it, as I seem to keep feeling the need to bring it
up again. For now, interested parties can check out my Hotspot
article at developer.com:
http://www.developer.com/journal/techfocus/052598_hotspot.html
Or this response to a questions about exceptions and performance:
http://www.artima.com/flexiblejava/fjf/exceptions/messages/18.html
My own feeling concerning the main point of this question
is that I would probably try to minimize the amount of code
that is synchronized so that it is just the actual critical
sections, because the more non-critical-section code that
ends up being synchronized, the longer threads that are
blocked waiting for another thread to release a monitor will
have to wait before getting unblocked. So in general,
if the critical section is just a few statements inside a
method, I'd wrap those few statements in a synchronized block
rather than make the whole method synchronized. The one situation in which I can imagine that this way of
thinking may break down is if you have a bunch of synchronized
blocks sitting in the same method separated by only a small
amount of unsynchronized code. In a case like that, the
performance overhead of getting the lock every time wouldn't
likely be worth any benefit that comes from releasing the
monitor for a short time between the synchonized blocks.
Perhaps this is what the article you speak of was talking about. In other words, I'd probably synchronize an entire method if
slavishly obeying my just-synchronize-the-critical-sections
rule would lead me to the following kind of code:
void someUnsynchMethod() { synchronized(this) {
do some critical section stuff;
} do something piddly that isn't a critical section; synchronized(this) {
do some more critical section stuff;
} do something else piddly that isn't a critical section; synchronized(this) {
do some more critical section stuff;
} do something else piddly that isn't a critical section; synchronized(this) {
do some more critical section stuff;
}
}
Does anyone else out there have any ideas about this question? bv
Replies:
|
