choice between notify and notifyAll

[Helen Ma]

Hi,
I am reading Monkhouse's book about choosing notify and notifyAll. When there is only one waiting thread, it is recommended to use notify. When there are multiple waiting threads, it is recommended to use notifyAll.
During iterative development, if I am not sure how many waiting threads will be (maybe just one or multiple), should I choose notifyAll ?

[Roberto Perillo]

Helen Ma wrote:should I choose notifyAll ?

Yes. Many clients may be waiting to be notified. If you use only notify, then only one client will be notified, and the others will wait forever... which will cause a deadlock.

[Roel De Nijs]

Exactly what my good buddy Roberto has said, but with a bit more explanation.

When you have multiple threads waiting and you use notify, you don't know which thread will be notified. So the thread that was notified, could be waiting for another event to happen. When it finally enters running state, it discovers that nothing has changed (because it was a completely other event that triggered the notify) and goes back to waiting state. And you have some threads waiting forever... (and that's not a good thing )

[Helen Ma]

So, during software development, if I am not sure how many threads are waiting, the better choice is notifyAll. If in one circumstance only one thread is waiting, should I choose notifyAll? Because in the exam, I may encounter some situations that I don't know how many waiting threads waiting (can be only 1, can be multiple), I think choosing notifyAll over notify is better.

[Roel De Nijs]

True. Or you could opt for the new concurrency api. It's more high-level and you can make a thread wait for conditionA and another one for conditionB. An example can be found here. If I would take the certification today, I would definitely choose to use the new concurrency api instead of wait/notify(All).

[Helen Ma]

Hi, Roel.
In Monkhouse' book, it will talk about await, lock methods in Chapter 5. So, for exam or developement, I should choose the new concurrency API over wait/notify(all) to get full credit or get better performance.

[Roel De Nijs]

No, you certainly don't need to use new api to get full credit (I used wait/notify and got perfect score). But I would now simply use this new api, because it has some advantages which are described here.

[Helen Ma]

Hi, Roel, from the site you posted : http://www.baptiste-wicht.com/2010/09/java-concurrency-part-5-monitors-locks-and-conditions/
There is a paragraph:
...it will be easier to use the synchronizated keywoard on the two methods. But with synchronized, we will not have the condition variables. If you don't need condition variables but only
locking, it will be easier to use the synchronized blocks instead of Locks."

Even though I don't know what condition variable it is refering to, but it seems like there are pros and cons between synchronized block and Lock.

Is Lock a replacement of synchronized keyword?

[Roel De Nijs]

From the javadoc of ReentrantLock:

A reentrant mutual exclusion Lock with the same basic behavior and semantics as the implicit monitor lock accessed using synchronized methods and statements, but with extended capabilities.

I think for this (simple) assignment using wait/notifyAll in combination with synchronized will definitely be enough. If you are already familiar with it, I would suggest to use new concurrency api in your application because doing that you'll learn something new. When you have 2 (or more) technologies, it's always about making a decision based on the pros and cons.

[Roel De Nijs]

If you need to make a choice betweet notify and notifyAll it has not only to do with the number of threads that could be waiting, but also with the functionalities of your program. Because in the assignment you must also be able to delete records, you have to use notifyAll instead of notify; otherwise you might end up with a program which never finishes.

An example to illustrate: T1 wants to delete record1, T2 and T3 want to update record1.
a) T1 locks record1
b) T2 and T3 have to wait until record1 is unlocked
c) T1 deletes record1

When using notify:
d) T1 unlocks record1 --> 1 waiting thread (in this example T2) is notified
e) T2 wakes up, sees that record1 doesn't exist anymore and throws a RNFE
f) T3 still waits for record1 to be unlocked, but that will never happen again (because it's deleted) and your program will never finish

When using notifyAll:
d) T1 unlocks record1 --> all waiting threads are notified
e) T2 wakes up, sees that record1 doesn't exist anymore and throws a RNFE
f) T3 wakes up, sees that record1 doesn't exist anymore and throws a RNFE
g) your program runs to completion without any problem