wait() , notify() - which thread first unlock?

Question

Trying to understand wait() and notify(). I know when thread A went to wait() it will be waked up by notify() from other thread.

But what will happens if threads A,B,C went to wait() in represented order? Who will be waked up by notify()? According to my experiments A thread will be waked up at first. I'm right?

Does it means that system knows in which order threads went to wait() ?

There is no such guarantee, see also http://stackoverflow.com/questions/30471285/what-is-the-difference-between-wait-notify-and-wait-interrupt and http://stackoverflow.com/questions/37026/java-notify-vs-notifyall-all-over-again — Mark Rotteveel, Nov 05 '16 at 10:14

score 8 · Answer 1 · answered Nov 05 '16 at 10:15

From the documentation for notify(), emphasis mine:

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.

Some other APIs, such as Semaphore, have a concept of "fairness", where you can ensure that threads do proceed in the order in which they blocked.

score 2 · Answer 2 · answered Nov 05 '16 at 10:18

2

Section 17.2.2 Notification of Java Language Specification:

There is no guarantee about which thread in the wait set is selected.

So, observed behavior is not guaranteed and should not be relied upon.

answered Nov 05 '16 at 10:18

kgeorgiy

1,477
7
9

Alessandro Moraes · Answer 3 · 2016-11-09T12:18:16.277

2

No, the VM does not know in which order the threads were put in Waiting state.

When you call notify(), one of them will be back to Alive/Runnable state and there is no way to know which one the VM will choose.

Sometimes they can run in the order they were put in Waiting state, but the specification does not guarantee that. So in a different VMs you can have a completely different results or even in the same VM, if you run the code multiple times.

edited Nov 09 '16 at 12:18

answered Nov 05 '16 at 10:20

Alessandro Moraes

116
8

1

That's incorrect - the OP was talking about `notify()` and that method only puts one thread in the runnable state. You must be thinking of `notifyAll()` – Erwin Bolwidt Nov 07 '16 at 02:15
Thanks @ErwinBolwidt, you're right, I've just corrected the answer. I was thinking about notifyAll() – Alessandro Moraes Nov 09 '16 at 12:19

score 1 · Answer 4 · answered Nov 05 '16 at 10:16

No, there is no guarantee about the order. The javadoc of the notify method is pretty clear on this:

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.

score 1 · Answer 5 · answered Nov 07 '16 at 03:37

There's no such an order. Either thread has an equal opportunity to get into runnable state. Actually JVM/OS can see them only as a set of waiting threads, they don't know any order.

In terms of your experiment, to get into a fair conclusion, actually you have to perform it for a huge number of times.

In threads, you can expect an order (FIFO), only if you are using something like a strong Semaphore. Then these threads are put into a waiting queue and fist comer would be first served.

wait() , notify() - which thread first unlock?

5 Answers5