File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Performance and the fly likes synchronized block/method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Performance
Bookmark "synchronized block/method" Watch "synchronized block/method" New topic
Author

synchronized block/method

mohan dodderi
Ranch Hand

Joined: Aug 23, 2004
Posts: 69
what will happen if a synchronized block/method is called in between many other statements.my dought is after calling synchronized method ,is there any chances of poor performance in the execution like slowing the execution.

[edited the subject to be more expressive - Ilja]
[ August 30, 2004: Message edited by: Ilja Preuss ]
Oneal Shaha
Ranch Hand

Joined: Aug 11, 2004
Posts: 98
Mohan,

Any code in synchronised block can be accessed by at most one thread.

So unless one thread completes its execution on the particular block the other threads have to stop. Now this may look like the threat to the performance. But in order to avoid havocs and deadlock it is necessary to put some code in synchronized block.

So if the performance is lowering due to this... There is no other option


-Oneal
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
mohan d.s,

Welcome to JavaRanch!

We ain't got many rules 'round these parts, but we do got one. Please change your display name to comply with The JavaRanch Naming Policy.

We'd like something more than initials for the displayed last name.

Thanks Pardner! Hope to see you 'round the Ranch!


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Since your question seems to be concerned about a performance issue, I'm moving this to the Performance forum...
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
"remember, once a thread enters any synchronized method on an instance, no other thread can enter any other synchronized method on the same instance. however nonsynchronized methods on that instance will continue to be callable". Herbert Schildt (The Complete Reference Java 2)

offcourse, synchronized blocks are preferred. it doesn't block the larger piece of code.
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
Standard Java thread synchronization can cause performance problems, but there are other ways to achieve the same goals.

First, be sure you need synchronized. Access to a volatile variable will often achieve what you need. This is not free, but it's cheaper than synchronized. Any variable other than types long and double is atomic for free (you won't get a half-changed value) but you may get an old value unless the variable is also volatile.

If you have mostly read access with some write access, you need Reader/Writer locks, otherwise called shared and unshared locks. This is well covered with code you can use in the book "Taming Java Threads" by Allen Holub.

Sometimes the problem is not excessive blocking but that the overhead of Java synchronization itself is too much. Try organizing your classes so that each thing you need to do uninterruptibly is atomic.

This is a big topic but I hope these ideas will get you started.


Mike Gershman
SCJP 1.4, SCWCD in process
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by adeel ansari:
offcourse, synchronized blocks are preferred. it doesn't block the larger piece of code.
Not sure whether that's all that "of course", and a synchronized block is usually not necessarily any finer grained than a synchronized method.

- Peter
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Mike Gershman:
Standard Java thread synchronization can cause performance problems, but there are other ways to achieve the same goals.
Mmmm, that's grabbing the cow entirely by the wrong end of the horns, or something I'd say rather: Java thread sychronization overhead is not nearly as high as some have you believe. Just synchronize your code carefully, avoiding deadlocks and making sure that the critical sections aren't longer than necessary. Don't worry about anything else unless (a) you have a performance problem (b) a profiler has shown you that synchronization is the culprit (c) your critical sections are as small as you can make them and (d) you know exactly what you are doing. BEWARE. Here be dragons.

First, be sure you need synchronized. Access to a volatile variable will often achieve what you need. This is not free, but it's cheaper than synchronized. Any variable other than types long and double is atomic for free (you won't get a half-changed value) but you may get an old value unless the variable is also volatile.
Using neither synchronization nor volatile means that you get few guarantees on the behaviour you can expect. Nondeterministic behaviour is not good. Regarding the use of volatile, well, a volatile double or long should be atomic according to the JLS, but on many JVMs it isn't. As I said, here be dragons. For goodness' sake please stay with run of the mill synchronization unless you have demonstrated a need for something else and know exactly what you are doing.

If you have mostly read access with some write access, you need Reader/Writer locks, otherwise called shared and unshared locks. This is well covered with code you can use in the book "Taming Java Threads" by Allen Holub.
Holub, hmmmm... well. Another pattern of note for mostly-read access is to have a volatile immutable object that holds the state; to change the state, simply change the object for a fresh one. It is worth mentioning Doug Lea's util.concurrent package which has battle-hardened implementations of many concurrent programming constructs, R/W locks among them. It is well thought out and useful enough for Sun to make it part of the JDK platform in Tiger (java.util.concurrent.*). This is also a good point to plug his Concurrent Programming in Java book. I'll leave it up to the reader to make up their minds of its merits relative to Holub's book.

Sometimes the problem is not excessive blocking but that the overhead of Java synchronization itself is too much.
When exactly is this? Can you quote any examples from your own experience? I would contend that too little synchronization, which is consequently too coarse (large critical sections) or too inconsistent, is far more often a problem than the overhead of the Java synchronization mechanism. I'm not saying that this is never the case. All I'm saying is that it is just about the last thing a concurrent programming newbie should be concerned about.

- Peter
[ August 30, 2004: Message edited by: Peter den Haan ]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I think Peter's pretty much outline my opinion on this as well. volatile's a mess: don't use it(as Holub also advises). By and by, synchronization doesn't kill performance: contention does.

M
[ August 30, 2004: Message edited by: Max Habibi ]

Java Regular Expressions
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
Java thread sychronization overhead is not nearly as high as some have you believe

I am too new at this to offer my own examples, but my professor in grad school has extensive commercial experience in Java and described substantial overhead.

The biggest issue with synchronized is the lack of shared locks. It doesn't support most strategies for minimizing blocking.

As for some jvm's not fully supporting volatile, are you sure? I thought the point of Sun keeping a trademark on the Java name was to assure users that all implementations met the spec. Wasn't that the point of the Microsoft litigation?

I thought that one advantage of using a high level language was that you could count on it to perform as advertised. Do we have to test every feature personally? Not properly supporting volatile would be particularly lethal as it's a hard bug to spot.

Is there a good summary on Java specs not always supported by jvm's. That would be a real dragon's den!
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Mike Gershman:
I am too new at this to offer my own examples, but my professor in grad school has extensive commercial experience in Java and described substantial overhead.
Well, of course I know neither your professor nor the extent of his experience. All I can say is that I've done the odd project myself, and some of my code is running here handling >10M page hits/month on two low end boxes: the first thing you hit is a short-term cache of compressed HTML responses implemented as a servlet filter written by yours truly. Server hits are many times that, I seem to remember we topped 100M once. My experience is that in most contexts the overhead of Java locking primitives is negligible.

The biggest issue with synchronized is the lack of shared locks. It doesn't support most strategies for minimizing blocking.
But that has nothing to do with synchronization overhead, and everything to do with contention - and, as Max emphasised, that is something you neglect at your peril Having said that, I would sort-of-disagree with what you state here. The monitor lock primitive that Java supports is just that: a primitive you can use to build more sophisticated constructs. Nothing stops you from writing a perfectly good read/write lock in Java or, better still, use an off the shelf solution like Doug Lea's util.concurrent package mentioned earlier.

Your professor will no doubt be delighted that this package will be part of the core platform in Tiger (JDK 1.5). This should address any problem he has with Java's concurrent programming support although, of course, you could get the same thing for years by using Doug's package.

As for some jvm's not fully supporting volatile, are you sure? [...] I thought that one advantage of using a high level language was that you could count on it to perform as advertised.
Yes, and I was shocked as well. This is where science turn into the arcane. Every programming language has some of this - although with some, for example Perl, it starts immediately after "hello world"

- Peter
[ August 31, 2004: Message edited by: Peter den Haan ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: synchronized block/method
 
Similar Threads
Problem in synchronized
syncronization in JAVA
a Thread Q
Mutually Exclusive lock
Difference between synchronized method and synchrozed block