Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
Cheo Gomez
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 21212
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Cheo Gomez
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Pie
Posts: 21212
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic