In the book I'm reading it says:
This technique is needed due to a race condition that would otherwise exist between setting and sending the notification and testing and getting the notification. If the wait() and notify() mechanism were not invoked while holding the synchronization lock, there would be no way to guarantee that the notification would be received.
Don't understand what this exactly means, why can the race condition happen?
EDIT: Hmmmm, I see now that this is possibly a duplicate question of Why must wait() always be in synchronized block , but it seams that the answers focus on making the condition check and going to wait synchronized.
Counterexample from shrini1000:
I can still do something like:
while(!condition) { synchronized(this) { wait(); } }
which means there's still a race between checking the condition and waiting even if wait() is correctly called in a synchronized block. So is there any other reason behind this restriction, perhaps due to the way it's implemented in Java?
It must be all about the technique author must have presented before the article you have copied in question. I am not sure which book you are reading but I will try to answer this question.
I read a similar book "Thinking in Java" that talked about the same race condition. It suggests that this can be prevented using wait and notify so that the code doesn't miss the notify signal.
T1:
T2:
The (setup condition for T2) is an action to prevent T2 from calling wait( ), if it hasn’t already.
The solution is to prevent the race condition over the someCondition variable. Here is the correct approach for T2: