aspose file tools*
The moose likes Java in General and the fly likes Doubt with a thread question about Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Doubt with a thread question about "synchronized(sa)"" Watch "Doubt with a thread question about "synchronized(sa)"" New topic
Author

Doubt with a thread question about "synchronized(sa)"

Cheo Gomez
Greenhorn

Joined: Jan 24, 2012
Posts: 25
Hi comunity, I have a doubth with this question, I dont understand, when they made the call to syncronized(sa) in the main method, what object they are sincronizing?


Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18988
    
  40

Please don't do this...



Remember that synchronization is based on objects -- and not references. So, changing the reference to another object means that the same code can run in parallel, as it is two different objects. It also means that previous calls to the wait() method won't get the notification, because it too, is using a different object.


Please don't do this... it doesn't work.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Cheo Gomez
Greenhorn

Joined: Jan 24, 2012
Posts: 25
the main thread has the lock of SA?
does the wait method gets called?
the run method is executed in this code?
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18988
    
  40

Cheo Gomez wrote:the main thread has the lock of SA?
does the wait method gets called?
the run method is executed in this code?


As already mentioned, the code is broken, so the example is really moot. However, if you want possible examples of what happens, here are a few possibilities.

1. If the t1 thread gets to lock SA, before the main thread changes it to "Done" -- meaning locks the "Not Done" object. It will then call wait(), hence release the lock on the "Not Done" object. Later, the main thread locks the "Not Done" object, changes it "Done", and sends the notification on the "Done" object. Unfortunately, the other thread is waiting on the "Not Done" object, and hence, doesn't get the notification.

2. If the main thread gets to lock SA first, meaning locks the "Not Done" object. It will change it the "Done" object. And send the notification. Later, the t1 thread, may either lock the "Not Done" or the "Done" object, depending whether the main thread changed it at the time the t1 thread reaches the synch block. It really doesn't matter which object it locks, as in both cases, it will see "Done" (in the "if" condition), and *not* call the wait() method.

[EDIT] -- Oops, just realized the sa reference for the main thread is not the same sa reference as the t1 thread. The t1 thread always see the "Not Done" object. It will wait on the "Not Done" object. And never see the "Done" object or the notification sent on it.

Henry
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Cheo Gomez wrote:Hi comunity, I have a doubth with this question, I dont understand, when they made the call to syncronized(sa) in the main method, what object they are sincronizing?


None.

The idea that we "synchronize an object" is incorrect.

Rather, we synchronize on an object, which means only that we obtain that object's lock.

Syncing works like so:
Every object has an inherent "lock". Whenever we do synchronized(X), what that means is that we want to grab the lock for the object that X points to, and that we'll stop there and wait until that lock is released if some other thread currently holds it. That's all that syncing does*. Everything else is built on top of that.

*It also ensures that the current thread's local copies of shared variables are copied to and from main memory, but that part isn't relevant to the mutual exclusion and atomicity stuff we're talking about here.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Doubt with a thread question about "synchronized(sa)"