notify and notifyAll doubt

[mark stone]

say there are 3 thread now in the waiting pool. and there is one thread which has the lock or monitor and is running.
now this thread which has the monitor or lock is to give a call to notify or notifyAll. and after this the sync method execution is done or completed and it gives away the lock.
Now here is my doubt. if there was a call to notify then one of the thread in the waiting pool would go into the Ready-to-Run state. right ?
if this is correct then say instead a call to notifyAll was made. then in this case would all the threads in the waiting pool be elevated to Ready-to-Run state ? Or is it that only one thread would be sent to Ready-to-Run state ? this part is not clear. what actually happens in case of call to notifyAll ? what is the difference then between notify and notifyAll ?
because at the end only one thread would actually go into running state amongst all the threads in the pool of waiting threads.
can someone please clarify or rather let me know if this is correct in my understanding.

[Ragu Sivaraman]

When you use notify you can alert only a single thread to move on to the ready-to-run state..
If there are more than one thread waiting to contest for the lock then it wont help
Use notifyall() instead, which will broadcast to all the waiting for lock threads that the lock is available and you guys can contest and stuff...
Now which thread gets to own the lock and work on the synch code...hmm that's a million dollar question becoz it is implementation specific..
Ragu

[William Brogden]

With notifyAll, all waiting Thread are removed from wait state. Of course, they are still all blocked trying to re-enter the synchronized method they called wait from. Which one gets to actually run when the monitor becomes available depends - as Ragu said - on the implementation.
Bill
------------------
author of:

• Java 2 Exam Prep
  
• Java 2 Exam Cram
  
• Java Developer's Guide to Servlets and JSP
  
• Soap Programming with Java
  

[mark stone]

ragu, then what's the point of notifyAll instead of notify. In the end only one thread gets the monitor or lock. i guess i am missing something here.
its like saying this is a candy (one only) and i got to give it one of you guys. One way is just whisper so that one guys hears it and he gets it. The other is I shout that here is a candy and all you guys want it now. But then after all i just pick one of you guys and he gets the candy.
so what's the big deal here ! i guess i am missing something here.

Originally posted by Ragu Sivaraman:
When you use notify you can alert only a single thread to move on to the ready-to-run state..
If there are more than one thread waiting to contest for the lock then it wont help
Use notifyall() instead, which will broadcast to all the waiting for lock threads that the lock is available and you guys can contest and stuff...
Now which thread gets to own the lock and work on the synch code...hmm that's a million dollar question becoz it is implementation specific..
Ragu

[Ragu Sivaraman]

Originally posted by mark stone:
ragu, then what's the point of notifyAll instead of notify. In the end only one thread gets the monitor or lock. i guess i am missing something here.
its like saying this is a candy (one only) and i got to give it one of you guys. One way is just whisper so that one guys hears it and he gets it. The other is I shout that here is a candy and all you guys want it now. But then after all i just pick one of you guys and he gets the candy.
so what's the big deal here ! i guess i am missing something here.

Good point.. Well here is how it is..
From JLS:
Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.
There is no rule that notify must be used in a single threaded or single thread competeing environment. It is even applicable to a multi-threaded environment But from a programmer's prespective you choose to notify a single thread that's all. To co-relate to your analogy... you tell the class teacher (our jvm implementation ) that you wanna give this candy to a kid. The kids have no clue about your candy . It is the class-teacher decides which kid to get based on (certain criteria, in case of jvm priority based or round robin or something else...)and informs that kid alone
In a way it is very discriminating since most of the threads wont even have an opportunity to content for the lock..(most of the kids dont even know that you have a candy to give...)
notifyAll:
From JLS:
Wakes up all threads that are waiting on this object's monitor. A thread waits on an object's monitor by calling one of the wait methods.
In this case , you inform all the kids that you have a candy and you play a fair role of broadcasting the message but then again you give the candy to the class-teacher who has the final authority to give it based on the criteria...
In both the case the lock/candy is just one.
The participation to content varies from a single thread to multiple threads
HIH
Ragu