aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes synchronized Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "synchronized" Watch "synchronized" New topic
Author

synchronized

M Rama
Ranch Hand

Joined: Mar 04, 2005
Posts: 91
I have the following question:

What will happen when the following code is compiled:



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:



This does print 7

Can someone explain what is going on?
denny erwin
Greenhorn

Joined: Mar 28, 2005
Posts: 1
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
Ranch Hand

Joined: Apr 10, 2005
Posts: 195
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.


SCJA 1.0 (98%), SCJP 1.4 (98%)
M Rama
Ranch Hand

Joined: Mar 04, 2005
Posts: 91
Joe Sanowitz:
Excellent explanation. Makes sense. Thank you.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: synchronized