• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

synchronized

 
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Joe Sanowitz:
Excellent explanation. Makes sense. Thank you.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic