synchronizing a block of code

[Dale DeMott]

What exactly does the line
synchronized (letter)
do for me in this code??? I'm a bit confused by this.
-Dale

package net.javagroup.certification;
public class InSync extends Thread{
public StringBuffer letter;

public InSync() {
super();
}
public InSync(StringBuffer letter) {
this.letter = letter;
}
public static void main(String[] args) {
StringBuffer sb = new StringBuffer("A");
new InSync(sb).start();
new InSync(sb).start();
new InSync(sb).start();

}
public void run() {
synchronized (letter) {
for (int i = 0; i < 100; i++) {
System.out.println(letter);
}
System.out.println();
char temp = letter.charAt(0);
++temp;
letter.setCharAt(0, temp);
}
}
}

[Mehul Sanghvi]

Hi..
In this code "letter" is acting as a monitor object to the block. Any thread wanting to access the block which it is guarding will have to ask him for the access and if any other thread is still running within the guarded block, the second thread would be made to wait just outside the block.
Regards,
Mehul K. Sanghvi.

[Peter den Haan]

Some more thoughts...
I guess this code wants to illustrate why you might need to use a synchronized block, rather than simple synchronized methods. In this case, one single "letter" object is shared between all three threads and you need to coordinate access to it in some way. A synchronized method wouldn't work as each InSync object has its own monitor lock.
Whenever I see a synchronized block, my knee-jerk reaction is to check whether the code contained inside the synchronized block actually should be part of the object you're synchronizing on. In this example, though, you couldn't move the code into (a subclass of) it even if you'd want to - StringBuffer is final.
- Peter

[Mehul Sanghvi]

Peter den Haan
bartender
Member # 862

Whenever I see a synchronized block, my knee-jerk reaction is to check whether the code contained inside the synchronized block actually should be part of the object you're synchronizing on. In this example, though, you couldn't move the code into (a subclass of) it even if you'd want to - StringBuffer is final.
- Peter

Could you please make me understand the importance of having the code in the monitor object itself... e.g.: collections objects are used as monitors for their own synchronized blocks etc..

[Peter den Haan]

Originally posted by Mehul Sanghvi:
Could you please make me understand the importance of having the code in the monitor object itself...

It isn't always important. But a synchronized block can be a "code smell" that warrants investigation. A block that synchronizes on an object X usually contains some operation on X. Assuming this block is sitting in another class Y it may be that it is in fact more tightly coupled with X than with Y. If that is so it probably wants to be refactored into X.
Don't get me wrong. I'm not saying that this is always the case, just that it is worth checking for.
By the way, synchronized blocks are also often used in fine-grained synchronization, where an operation is split into multiple small synchronized sub-operations in an attempt to improve the concurrency of the code. Even then I would want to check whether the synchronized block can't be a separate (synchronized, private) method, as the code inside a block often represents a single, well-defined, discrete step and turning it into a method may clarify the code.
- Peter

[Jim Baiter]

But aren't there some benefits from using sync. blocks such as reducing the size of the critical section? Also you can use different objects to sync. on, e.g. Peter Haggar's book has examples where he has:
byte[] x = new byte[0];
...
public void somefunc() {
...
synchronized(x) {
...
}
...
}
I thought these were rather interesting.

[Mehul Sanghvi]

Hey guys,
Thanks.. I has helped me to look at it in a different angle.
Thanks again.
Regards,
Mehul K. Sanghvi.

[Peter den Haan]

Originally posted by Jim Baiter:
But aren't there some benefits from using sync. blocks such as reducing the size of the critical section?

Not compared to the very same chunk of code sitting in a method

Also you can use different objects to sync. on

Absolutely. A couple of classes in the JFC use a monitor object, a new Object() created simply for its monitor lock. Take a look at java.io.File for example. Synchronized blocks are also necessary in other cases, e.g. an iteration over a (threadsafe) Collection must generally be synchronized on the Collection.
- Peter

[Mehul Sanghvi]

originally posted by Peter Hann Den
Not compared to the very same chunk of code sitting in a method

How would the same piece of code make a difference as to where it is place i.e within a method or as a seperate method having both of them synchronized?
Thanks in Advance.
Regards,
Mehul K. Sanghvi.

[Mehul Sanghvi]

Sorry Peter, for goofing up while writing your name.. :roll:
As though we Indians are good at First Names..!!

Regards,
Mehul K. Sanghvi.

[Peter den Haan]

Sorry if I confused you. What I meant to say is that you don't necessarily need synchronized blocks to reduce the size of the critical section. A synchronized block

...
synchronized (this) {
   this.foo();
   this.bar();
}
...

has no benefits whatsoever over

...
this.foobar();
...
private synchronized void foobar() {
   this.foo();
   this.bar();
}

To the contrary, the latter form is often more readable as "foobar" is usually a single well-defined concept. In general, code that outlines an algorithm in high-level method calls is much easier to read and maintain than code that goes into implementation details straightaway.
It's not always easy or obvious to do this, though, specifically if there are multiple temporary variables being used. At the same time multiple temporary variables in a complicated method can make the code hard to understand, in which case it's worthwhile to see if things can be broken up or otherwise simplified.
- Peter
PS. Don't worry about my name you should see the indigities it had to suffer at the hands of the British since I hopped across the channel!
[ February 15, 2002: Message edited by: Peter den Haan ]