synchronized

[M Rama]

I have the following question:

What will happen when the following code is compiled:

public class TestThread extends Thread {
private int data = 7;
 
public synchronized void foo() {

start();
try {
sleep(1000);
} catch (InterruptedException e) {
}

data = 100;
data += 20;
data += 3;
 

}
 
public synchronized void run() {
System.out.println(data);
 
}
public static void main(String[] args) {
TestThread t = new TestThread();
t.foo();
}
}
 

The answer is: 123

The reason given is, since run method is synchronized, the start() doesn't trigger run() until the foo() method is completed. But the doubt I had is its the same object, and if you have lock to the object, you should be able to access all synchronized methods.

Adding to that, when I change the code to the following:

public class TestThread extends Thread {
private int data = 7;
 
public synchronized void foo() {

run();
 

data = 100;
data += 20;
data += 3;
 

}
 
public synchronized void run() {
System.out.println(data);
 
}
public static void main(String[] args) {
TestThread t = new TestThread();
t.foo();
}
}
 

This does print 7

Can someone explain what is going on?

[denny erwin]

I see that when you changed your code you called run(), not start(). Therefore no thread was actually created when you instantiated the class and the run() method executed like any other method.

[Joe Sondow]

That's a very interesting situation. Let's follow the sequence of events of the first code sample...

1. In the main thread of execution, the main() method creates the Thread object t and calls foo() on it. Since foo() is synchronized on the t object, no other synchronized method of t can execute from an outside thread of execution until foo() returns or otherwise gives up its lock on t.

2. The foo() method calls start(), which creates a second thread of execution in which the run() method will execute, and then the start() method immediately returns.

3. Because the run() method is synchronized, it cannot begin executing until the lock on t becomes available, and foo() still has that lock, so the second thread of execution where run() will execute goes into a blocked/waiting state because it cannot begin executing the run() method yet.

4. Next, the foo() method sleeps for a second and changes the value of the data member to 123.

5. The foo() method returns, giving up its lock on t.

6. The second thread of execution sees that the lock is available for the synchronized run() method, so it grabs that lock and executes the run() method.

7. The run() method prints the new value of the data member.

Now let's look at the sequence of events of the second code sample...

1. In the main thread of execution, the main() method creates the Thread object t and calls foo() on it. Since foo() is synchronized on the t object, no other synchronized method of t can execute from an outside thread of execution until foo() returns or otherwise gives up its lock on t.

2. The foo() method calls the synchronized run() method, which does not launch a new thread of execution. Since the main thread of execution already had the lock on t, there is no problem entering the synchronized run() method within the main thread of execution. Synchronization only prevents additional threads of execution from accessing the locked object. In this example there are no additional threads of execution.

3. The run() method prints "7" and returns to the foo() method.

4. The foo() method changes data to 123 and ends.

[M Rama]

Joe Sanowitz:
Excellent explanation. Makes sense. Thank you.