notify() vs notifyall()

[Vicken Karaoghlanian]

notifyAll() Will notify all waiting threads

notify() Will notify one of the waiting threads

the part i don't get is that on both cases there is only one thread that will be executed (determined by the JVM) whether i notified one thread or all of them.
so what is the difference between notify and notifyall?

[Anupam Sinha]

Hi Vicken
The difference is that when you call notify() only one thread will be notifed so only one thread will come out of the wait set of that object. The object that comes out of the wait set is chosen randomly, so you don't know which object would come out of the wait set. So we generally use notifyAll() method which causes all the waiting thread(on an object's wait set) to come out of the wait set.

[Vicken Karaoghlanian]

Anupam,
i clearly understand that, but what difference will it make if all threads were notified or only a single thread. in both casses there is only one thread selected randomly. And because there is only one thread that will come alive it mean that we only need to notify only that one (random) thread.
in the case of notifying all the threads they'll all wake up and start competing with each other until only ONE is selected, which brings us to the place we start.
so it doesn't make a difference if i noify all or just one, am i right?
[ August 09, 2003: Message edited by: Vicken Karaoghlanian ]

[w wu]

great ,is i want

[Jose Botella]

If all the waiting threads are performing the same tasks, and you do not care which of them to wake up, use notify because notifyAll would be a waste of time. All the threads except one will have to wait again; I assume we are using the compulsary wait loop.
If the threads are waiting on different conditions --the variable checked in the loop-- use notifyAll. Otherwise the solely woken thread could wait on a condition that did not change. It would have beeen woken to just becoming a waiting thread again, and what is worse, the notification would be lost because the right thread was not notified.

[Jose Botella]

I remember to have read that is advisable to use notifyAll whenever there is more than one waiting thread because some JVM could choose the thread to be woken based on the span of time the thread is in the wait set. If such implementation always chooses the more recently thread added to the set, and the set has always threads in it, the thread waiting for the longest time would not be chosen to wake up ever.
Ugly thing to depend on implementation details eh?
Does anybody know if this concern is still applicable?

[Anupam Sinha]

Hi Vicken
Yes, Only one thread be out of the loop. But which one. In order for us to continue processing it might be required that we want a particular thread to proceed. Consider this code

while(j!=1){wait();}

In this case all the other threads may also have a similar while loop and which checks some kind of condition. So now if t==1 then only the above code will allow the thread to continue and the other threads will keep waiting.

[Vicken Karaoghlanian]

It would have beeen woken to just becoming a waiting thread again

at least in this case it is only one thread that has been waken up and then gone to sleep, however if we have 100 thread and
we used notifyall() all the 100 threads will wake up ONLY to allow one thread to continue it work, while sending the
other 99 to sleep.
from my personal point of view i think that waking only one thread will be more efficient than waking 100.

I remember to have read that is advisable to use notifyAll whenever there is more than one waiting thread because some JVM
could choose the thread to be woken based on the span of time the thread is in the wait set. If such implementation always
chooses the more recently thread added to the set, and the set has always threads in it, the thread waiting for the longest
time would not be chosen to wake up ever.
Ugly thing to depend on implementation details eh?
Does anybody know if this concern is still applicable?

the point you made here is very interesting... i guess. but i think that the priority of the waiting threads increases
implicitly from time to time to prevent starvation.

it might be required that we want a particular thread to proceed

that is correct, however i think that waking only one thread will be more efficient than waking a dozen.

thank you all for your replies, i appreciated, but i am sorry to say that i am not yet convinced.
[ August 09, 2003: Message edited by: Vicken Karaoghlanian ]

[Jose Botella]

from my personal point of view i think that waking only one thread will be more efficient than waking 100.

The point if that if the threads are doing different tasks you cannot permit to notify only one (random) thread. The change of the waiting condition must mean a notification to a proper thread so that it continues with the task they are supposed to be collaborating on. If the randomly chosen thread was not waiting on that condition the notification is lost.
100 threads waiting on the same object does not looks like a good design!

[Vicken Karaoghlanian]

let say that we used notify() and the woken thread was not the one we need to satisfy some condition, isn't suppose that this thread goes back to sleep and a different thread wakes up?

[Jose Botella]

Not at all Only one thread is notified when using notify

[Vicken Karaoghlanian]

finally... that makes sense... thanks a lot... i appreciate it.

[Mahendra Deshpande]

The point if that if the threads are doing different tasks you cannot permit to notify only one (random) thread. The change of the waiting condition must mean a notification to a proper thread so that it continues with the task they are supposed to be collaborating on. If the randomly chosen thread was not waiting on that condition the notification is lost.

On the other hand if notifyAll() was used, then only thread, waiting on
that condition would be chosen, is that correct ?
I mean suppose notifyAll() was used, and then one particular thread
successed, but was not the thread waiting on that condition, then
another thread would be chosen. This process would continue, till
the thread which is waiting for that condition is found.
Is this correct ?

[Vicken Karaoghlanian]

hmmmmm... good point Mahendra, i thinks the statement you made is true, however you must wait for Jose's reply, just to make sure.
let suppose the answer is yes, this raise a new question... if the condition we are looking for can't be changed by any of the waiting threads, is it safe to say that the current thread is on a DEADLOCK condition?

[Anupam Sinha]

Hi Vicken and Mahendra
Well the thing is that all threads will compete for the lock and then it's upto the programmer to make sure that the correct thread is selected. It's not that the JVM will itself make sure that the thread you want will be selcted and thats why you need to use a loop as the one above in the posts.

[Vicken Karaoghlanian]

it's upto the programmer to make sure that the correct thread is selected

this can be achieved by controling the condition in the current thread, right?
[ August 10, 2003: Message edited by: Vicken Karaoghlanian ]

[Alexan Kahkejian]

Hi all
I am not sure if I missed something but if you check the API for notifyAll() here is what you find:

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.
The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.

So my understanding is that notifyAll makes all threads waiting on this object to go out of the waiting state but will compete with other threads and everytime the lock is available one thread will go to running state, which it isn't the case with waiting threads.
Plus I remember before a while I had the same confusion and wrote a small program which prove this but unfortunately I didn't found it now.
So if I was wrong please confirm because I'll take the exam this Tuesday.
Alexan

[Jose Botella]

You are right Alexan.
But because a condition-testing loop for wait is compulsary, if the awaken thread makes the condition false, all the rest will go to wait again:

synchronized(lock) {
    while(! condition) {
        try { lock.wait(); }
        catch(InterruptedException e) { }
    }
    //dou your thing
    condition = false;
}

This is not a working example, but just shows that if a thread calls lock.notifyAll() and condition is true only one awoken thread will grab the lock and proceed. The others will go to wait.
Notifications from one thread to other is like a kind of protocol. Hey I am done with my job, you can proceed with yours. See The Java Tutorial for an example called producer/consumer

[Mahendra Deshpande]

The tutorial suggested by Jose is an excellent one!! It really clarifies
lot of things on how one should use notifyAll.
Also, I have found an paragraph in
http://developer.java.sun.com/developer/Books/javaprogramming/begjava2/ch11.pdf
which says similar things what Jose, Anupam and Vicken are trying to say,
but states when to use notifyAll() and when to use notify(). Here it goes
--------------------------------------------------
It is generally better to use notifyAll() rather than notify() when
you have more than two threads synchronized on an object. If
you call notify() when there are two or more other threads
suspended having called wait(), only one of the threads will be
started, but you have no control over which it is. This opens
the possibility that the thread that is started calls wait()
again because the condition it requires is not fulfilled.
This will leave all threads waiting for each other, with no
possibility of continuing.
--------------------------------------------------
Thanks to Vicken, for raising this, it has really put some
light on my understanding of synchronization of threads.
Also, in a book, "Java High Performance Computing", chapter4
http://developer.java.sun.com/developer/Books/performance2/chap4.pdf
you would find exact point which Vicken has raised,
"Notifying all threads would be inefficient, when it is
not required" (See section Explicity Queues ).

[Praveen Kumar Mathaley]

consider the following example two
threads wait, and there's only one notify , but both threads comes out of wait status
package thread;
class TestThread extends Thread
{
public void startMe()
{
synchronized(this)
{
notify();
System.out.println("Notified...");
try
{
System.out.println("waiting in startME");
wait();
System.out.println("woke from wait in startME");
}
catch(InterruptedException e)
{}
}
}
public void run()
{
try
{
synchronized(this)
{
System.out.println("waiting in run");
wait();
System.out.println("woke up from wait in run");
}
}
catch(InterruptedException e)
{}
}
public static void main(String[] args)throws Exception
{
TestThread t1 = new TestThread();
t1.start();
Thread.sleep(1000);
t1.startMe();
}
}

[Gopal Shah]

Originally posted by Vicken Karaoghlanian:
but i think that the priority of the waiting threads increases
Does the priority of a thread ever increase/decrease during its lifetime ?

[Anupam Sinha]

Hi Gopal
Unless you yourself increase the priority it should not change. Though the operatin system may choose to run a thread that is waiting for a long time. It depends upon the Operating system.

[Vicken Karaoghlanian]

hi Gopal,

the priority of the waiting threads increases implicitly from time to time to prevent starvation.

i only assumed that this statement is valid in java, becasue it is one of the major concepts of Operating Systems. although i don't know if it is true for JAVA.
unless someone assures that this statement is correct, you should consider it invalid.