A question on JTest asks <pre> Which methods may stop a thread from executing? A. sleep() B. stop() C. yield() D. wait() E. notify() F. notifyAll() G. synchronized()
</pre> The answer given by JTest is A, B, C and D. What about E and F? I thought that notify() would stop the thread and give control to somthing that is waiting?
No. I believe it just takes a thread in the Monitor's (the Object with the synchronized methods/statements) pool and puts it into the Ready state. It does not force the current thread to yield.
You are correct that it does not release the CPU - this much I have figured out since posting that question. But, does it move it to the "ready" state, or the "waiting for lock" state? (is there a "waiting for lock" state?)
Umm, those terms are confusing. Monitor can be locked or unlocked. A thread can be waiting on monitor, having the monitor locked (resource is busy) or waiting for the monitor to unlock (waiting for a resource). So, notify() just tells the monitor the wait() should be finished, but doesn't change the monitor's ownership(locking). So, if you have one thread waiting on monitor and another doing notify() on the same monitor, the execution of the first thread will continue only after the second thread will release the monitor (exit 'synchronized' block).
------------------ With best of best regards, Pawel S. Veselov ( aka Black Angel )
With best of best regards, Pawel S. Veselov ( aka Black Angel )
According to RH Notify method selects one of the thread in the monitors waiting pool and moves it to Seeking lock state. Eventually when it gets the lock it is executed
You ridiculous clown, did you think you could get away with it? This is my favorite tiny ad!
a bit of art, as a gift, the permaculture playing cards