Well, for a start, it can't, because the notifying thread still holds the monitor lock. The JLS says the following about it:
Originally posted by Rams Senthiil:
I found a thread issues notify didnt invoke the waiting thread immedeatly, instead the same thread which issues notify keep on running until it executes few statements. I thougth once a notify is executed it should immedeatly transfers control to any waiting thread. [...]
"Every object, in addition to having an associated lock, has an associated wait set, which is a set of [waiting] threads. [...] Wait sets are used by the methods wait, notify, and notifyAll of class Object. These methods also interact with the scheduling mechanism for threads. [... A waiting] thread T then lies dormant until one of three things happens:
So notify() merely re-enables a waiting thread for scheduling; it will first has to compete for the object's monitor lock, and then it can still take a while for it to get its time-slice.
[ February 07, 2003: Message edited by: Peter den Haan ]
And because of this, any program that invokes notify() or notifyAll() should usually try to give up the lock as soon as possible after notifying. Either exit the synchronized block/method that you're in, or invoke wait() on the monitor whose lock you need to give up. (Assuming you're also going to eventually notify() the current thread when it can resume.) Otherwise you're just wasting the thread scheduler's time.
[ February 07, 2003: Message edited by: Jim Yingst ]