This actually depends a lot on the JVM+JIT you're using. With current JVMs
(i.e., 1.2.X) there no longer appears to be much benefit to obtaining a lock on
a monitor and holding it vs obtaining it separately each time. In my testing
the case of synchronizing on an object with the lock already held was only about
4% faster than synchronizing with the lock *not* held (Win32). This was much
more of an issue in the 1.1.X JVMs - 1.1.8, for instance, came out at about 20%
faster.
Just by the way, Sun also considerably improved the speed of all locking
operations in 1.2.1 vs 1.1.8. Synchronizing on an object with the lock not held
in 1.2.1 was about 25% faster than the 1.1.8 time for synchronizing with the
lock already held, and about 40% faster than the 1.1.8 time for synchronizing
with the lock not held.
Even with the older JVMs, doing an outer synchronize just to speed up three or
four inner synchronizes would be a net loss.
<CAVEAT> I recently had someone point out to me that my figures were obtained
running on single processor machines and may not carry over to multiprocessor
systems. I'm going to try the tests again when I have access to a
multiprocessor system to verify the results. </CAVEAT>
IMHO, it's very unfortunate that Sun decided, back in the dawn of the Java age,
that the working methods of StringBuffer should be synchronized, then compounded
the problem by mandating the use of StringBuffer anytime you do a String
concatenation. Somewhere around 99.99% of all StringBuffer use occurs in
situations where only one thread can possibly be using the StringBuffer
instance, yet all pay the penalty for synchronization.
- Dennis
Dennis M. Sosnoski
Sosnoski Software Solutions, Inc.
http://www.sosnoski.com
Chris Pratt wrote:
>
> I believe Alan Holub did some tests and found out that achieving a lock when
> one was already held was no faster then achieving the lock the first time,
> which would mean that your code would actually be slower.
> (*Chris*)
>
> ----- Original Message -----
> From: Alex Smith <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, August 16, 1999 2:56 PM
> Subject: Re: (SUGGESTION) OutOfMemoryException
>
> > This is grossly off topic -- I hope this message is the last in the
> thread.
> > Take this to private email, an appropriate forum on JDC or the Usenet
> > newsgroup(s).
> >
> > You can (and should) go one step further when working with StringBuffer,
> > namely synchronize on an instance when calling append(), like so:
> >
> > StringBuffer sb = new StringBuffer();
> > synchronized (sb) {
> >
> > sb.append("foo");
> > sb.append("bar");
> > sb.append("baz");
> >
> > }
> >
> > The append() methods of StringBuffer are synchronized in both 1.1
> > and 1.2, at least the ones actually doing any work. (Some simply convert
> the
> > argument to String and call an appropriate append()). There is an overhead
> > involved in grabbing and releasing the lock, so it is inefficient to free
> a
> > lock, just to grab it again a few lines of code later. Therefore, if
> you're
> > doing more than one append(), it is better to synchronize on an instance,
> > thereby freeing the JVM from the responsibility of re-acquiring the lock
> for
> > every append() call.
> >
> > Note: beware of JDK 1.2 API docs on Sun's website. It looks like
> > 1.2 javadoc omits (by design or explicit command-line arguments)
> > two out of three 'non-significant' (not used while computing a signature
> of
> > a method) modifiers, namely keywords "synchronized" and "native".
> Therefore,
> > you may be led to believe that 1.2 append() is not synchronized. This is
> not
> > true. Always read the source and trust noone :P
> >
> > Alex.
> >
> >
> > _______________________________________________________________
> > Get Free Email and Do More On The Web. Visit http://www.msn.com
> >
> >
> ___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
