Q on threads (2): synchronized and wait

[Gian Franco]

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

[Gabriel Forro]

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 ]

[Gian Franco]

Thanks Gabriel,
I like the room metaphore
Cheers,
Gian Franco

[V Bose]

I was going to say that too ...

[Gabriel Forro]

Thanks for the compliment
Gabriel

[Kaustubh Patil]

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..

[Gabriel Forro]

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 ]