Concept of wait(), notify() and notifyAll()

[Siddharth Bhargava]

Hi,

I am having a really hard time understanding the concept of wait(), notify() and notifyAll(). I have read the articles in the net as well as the books but I havn't got the concept behind the same. Would someone like to explain me the concept with some easy to understand examples. ?

Thanks and Regards,
Siddharth (Sid)

[Anurag Verma]

best place would be javadocs, did you go through that too? let us know what exactly you didn't get..Doing some hands-on will make stuff more clear, did you try that too?

[Tushar Goel]

Search previous posts on coderanch. You will find many on them.

[Stephan van Hulst]

What really helped me a few years ago was an article I read that made the analogy between object monitors and airplane bathrooms: http://www.nyu.edu/classes/jcf/g22.3033-007_sp01/handouts/g22_3033_h53.htm

If you have specific questions, please let us know.

[Siddharth Bhargava]

 

Anurag Verma wrote:best place would be javadocs, did you go through that too? let us know what exactly you didn't get..Doing some hands-on will make stuff more clear, did you try that too?

Yes I did went through the Java docs. What exactly does this line "The wait() method releases the lock prior to waiting and reacquires the lock prior to returning from the wait() method. The wait() method is actually tightly integrated with the synchronization lock, using a feature not available directly from the synchronization mechanism. In other words, it is not possible for us to implement the wait() method purely in Java: it is a native method.." mean ?

Also I could not understand the producer / consumer problem.

private void produce(int i) throws InterruptedException
{
synchronized (taskQueue)
{
while (taskQueue.size() == MAX_CAPACITY)
{
System.out.println("Queue is full " + Thread.currentThread().getName() + " is waiting , size: " + taskQueue.size());
taskQueue.wait();
}
Thread.sleep(1000);
taskQueue.add(i);
System.out.println("Produced: " + i);
taskQueue.notifyAll();
}
}

What is the purpose of taskQueue.notifyAll(); specifically ? Similarly in the below code:

private void consume() throws InterruptedException
{
synchronized (taskQueue)
{
while (taskQueue.isEmpty())
{
System.out.println("Queue is empty " + Thread.currentThread().getName() + " is waiting , size: " + taskQueue.size());
taskQueue.wait();
}
Thread.sleep(1000);
int i = (Integer) taskQueue.remove(0);
System.out.println("Consumed: " + i);
taskQueue.notifyAll();
}
}

Could you please explain me the producer / consumer e.g. using wait / notify / notifyAll ? Step-by-step what is happening specifically the code inside the synchronized block and after the while loop.

Thanks and Regards,
Sid

[Henry Wong]

 

Siddharth Bhargava wrote:
Yes I did went through the Java docs. What exactly does this line "The wait() method releases the lock prior to waiting and reacquires the lock prior to returning from the wait() method. The wait() method is actually tightly integrated with the synchronization lock, using a feature not available directly from the synchronization mechanism. In other words, it is not possible for us to implement the wait() method purely in Java: it is a native method.." mean ?

In my opinion, the quote doesn't really say anything that useful. Who cares if the wait() method can't be done purely in Java? Isn't that just an implementation detail?

Anyway, if you ever use any other threading environment, such as Solaris threads, POSIX threads, or even Windows threads, you have use this feature / functionality before. It goes by the name of "condition variable". And it is tightly integrated with an mutually exclusive lock (mutex), which in Java is implemented via synchronization. Java also implements the mutex and condition variable differently but that's for a different discussion.

What a condition variable does is atomically send a notification (signal) from one thread to another. To be atomic, it must use the mutex (must own the lock). And for the thread that must wait for the notification, it must free the lock -- or else, it won't be possible for the send thread to own the lock to send the notification.

And unfortunately, this can't be done without tightly integrating those two features. Not integrating it, will make it possible for notifications to be lost... and unfortunately, this may be a bit hard to envision.


Anyway, perhaps you should do some research on "condition variables" in general. Since, this feature is available with practically all threading environments, you have other documentation to rely on here (don't need to be specific to Java).

Henry

[Karthik Shiraly]

wait() -> you eat at your reserved table, while all the other customers wait outside for an empty table

notify() -> when you are done, the waiter goes out, picks one customer randomly, tells them an empty table is available. The rest continue to wait.

notifyAll() -> when you are done, the waiter just shouts "EMPTY TABLE" and this happens:

The table is the thing being synchronized here.
If it wasn't, you'd end up sitting next to a family with 3 brats, eating their cereal while they enjoy your fine (expensive) wine!

[Steffe Wilson]

 

Karthik Shiraly wrote:The table is the thing being synchronized here.

Wow. The first use case I've ever seen of

throws synchronized

[Karthik Shiraly]

Good one, Steffe!
Looks like this one went "unchequed".

[Joe Bishara]

The post with the YouTube video is so funny

Anyway, in reality, things should be a little more orderly:

call notify() if it doesn’t matter which customer (thread) gets to use the empty table. The thread scheduler will select one customer at random.

call notifyAll() if the empty table is a tall table and only tall customers (threads) should use it. Every customer will then fight for the table and eventually, a tall customer will get to use the table.