wood burning stoves 2.0*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Q on threads (2): synchronized and wait Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Q on threads (2): synchronized and wait" Watch "Q on threads (2): synchronized and wait" New topic
Author

Q on threads (2): synchronized and wait

Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
Hi,
I need some feedback on this one, please.
If I have a wait() in a synchronized method
doesn't this mean I am actually leaving the
'synchronized status' for a while, since the
locks are released?
And then I'm picking up the 'synchronized
status' again when I'm notified.
So I see this as doing some stuff that
can't be shared up until the wait(), leaving
for a while with the wait() call, and then
resuming with unsharable tasks...
Cheers,
Gian Franco


"Eppur si muove!"
Gabriel Forro
Ranch Hand

Joined: Apr 16, 2004
Posts: 59
Hi
Imagine an object is as a building. Its methods are rooms. Methods or blocks in the methods, as You know, can be either synchronized or not synchronized. Imagine, that the synchronized methods and blocks are rooms with a locked door and the unsynchronized ones are rooms with an opened door.
Every object has a lock (only one), which is like a key, which can open the closed doors. When a Thread would like to enter a closed room, it needs the key. And the big truth is, that there is only one key, so only one Thread can execute the synchronized methods.

Let us have two threads A and B. If A has a key (owns the lock), thread B has no chance to enter the closed rooms (synchronized methods) and it has to wait - it gets to the "blocked state".
At this moment thread A has the key. In the room, it noticed, that it can not carry on in its work (for example the temperature in the room is too high) so it execute the object's wait() method. The result is, that thread A gives back the key to the object and the object puts thread A to a pool, where thread A can wait.
At this moment the key is free and any thread can borrow it. For example thread B, which has been in the blocked state, got the key and know can enter the closed room (synchronized methods and blocks). It adjusts the termostat (to a lower temperature) and it knows, that it have to inform threads, which are in the waiting pool, so it calls the object's notify() (a random thread from the pool is informed) or the notifyAll() (every thread in the pool is informed) method. Thread B still owns the key as it is in a synchronized room! Thread A has notified (informed), that there is a different temperature now, so it would like to go back to the room he left, when it had called the object's wait() method. But the key is not free (thread B owns it), so thread A gets to the blocked state.
Thread B still can do some stuff in the synchronized rooms. when it exit the closed room, it gives back the key to the object, so another threads which are in blocked state, get chance to enter closed rooms (synchronized methods or blocks). For example thread A and it can finish its work, as the temperature is lower now.
[ May 08, 2004: Message edited by: Gabriel Forro ]

Gabriel
Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
Thanks Gabriel,
I like the room metaphore
Cheers,
Gian Franco
V Bose
Ranch Hand

Joined: Jul 10, 2003
Posts: 113
I was going to say that too ...
Gabriel Forro
Ranch Hand

Joined: Apr 16, 2004
Posts: 59
Thanks for the compliment
Gabriel
Kaustubh Patil
Ranch Hand

Joined: Aug 13, 2001
Posts: 164
Hey.. Nice analogy.. that was gr8..
But I got confused at the stage where the key passes on from A to B. I guess if A is waiting for certain condition and then it shouldn't have got the key in the first place.
May be I am wrong.. but..


Kaustubh. Mumbai, India.
Gabriel Forro
Ranch Hand

Joined: Apr 16, 2004
Posts: 59
Hello Kaustubh,
When thread A invoke the object's wait() method, the key (object's lock) is given back to the object. At this moment the threads, which have been blocked because of waiting for the key (need the key to enter synchronized rooms - invoke an object's synchronized method or block) change their states from blocked to runnable.
After that, one of the threads, which are in runnable state, will be the winner and will obtain the key. Which thread will be the winner? We can not be sure. It is JVM implemetation depended.
If there is only thread B, well it will be the happy winner. If there are other ambitious threads with the same priority, well B's chance are less than 100%.
[ May 09, 2004: Message edited by: Gabriel Forro ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Q on threads (2): synchronized and wait
 
Similar Threads
wait method
Deadlock with multiple clients
Issue with wait/notify
wait()
wait() and a freezing gui.