This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes synchronization and locks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "synchronization and locks" Watch "synchronization and locks" New topic
Author

synchronization and locks

dennis zined
Ranch Hand

Joined: Mar 07, 2003
Posts: 330
Hi all. In the code below t has a lock on l object when it enters the synchronized method1 at line 22(or at least thats what I think) and then waits at line 25. But how come t2 was able to execute method2 at line 31 which is also a synchronized method? My understanding (based on the K&B book) is that every object in Java has a built-in lock that only comes into play when the object has synchronized method code. Since there is only one lock per object, if one thread has picked up the lock, no other thread can enter the synchronized code (which means any synchronized method of that object) until the lock has been released.

However, modifying the code a bit to use sleep in lieu of wait at line 25 does lock the object. How is it that lock works if I use sleep and not for wait?

Thanks.


SCJP 1.4<br />SCWCD 1.4
Vad Fogel
Ranch Hand

Joined: Aug 25, 2003
Posts: 504
Hi, calling wait() on an object instance sends a currently executing thread to a waiting pool while making it relinquish the lock on this object. After this point, if another thread attempts to enter the code that is sync-ed on the same object, it'll succeed. In your example, it's method method2(). Calling notify() lets a waiting thread know that the lock on the object it's blocked on is about to be released soon (but not right away). So, while thread 1 is blocked, the lock becomes available to thread 2. Notice, however, that nothing is guaranteed flow wise in your first example. If thread 2 is chosen to run first, the program will never complete blocking in method1()!
The second example uses Thread.sleep() to put a currently executing thread (obviously, thread 1) to sleep. While sleeping, a thread retains all its locks, so there's no way that thread 2 completes if thread 1 started first. And again, nothing is guaranteed by the scheduler. Thread 2 may run before thread 1.
dennis zined
Ranch Hand

Joined: Mar 07, 2003
Posts: 330
Awesome. Thanks Vad.
dennis zined
Ranch Hand

Joined: Mar 07, 2003
Posts: 330
I just found out I can lock just a portion of my method as opposed to the entire object. Line 29 uses the lock of another object rather than use its own. That other object is declared static on line 18 so that no two threads can lock on the same piece of code otherwise using synchronize would be useless. So while that portion is locked other threads can also lock the same object using the object's own lock or again use some other object's lock.
I'm just blown away on how powerful thread stuff is. Would anybody know a good book on good multi-threaded design?
Vad Fogel
Ranch Hand

Joined: Aug 25, 2003
Posts: 504
Dennis, what you've mentioned above is a popular programming technique - synchronizing on a dummy object. It's got its own pros and cons, and that discussion has been up for awhile. Synchronizing your code is a trade off of performance vs. consistency or security if you will. What code needs synchronization is solely up to the designer.
You may be interested in perusing the following two maestros of concurrent programming:
Paul Hyde
Doug Lea
Both are very fundamental helping you create intuitive understanding of threads.
 
wood burning stoves
 
subject: synchronization and locks