After invoking the wait method on an object, obj1, a thread, T1, will remain in the wait set of obj1 until which of the following occurs? a. Another thread invokes the notify method on the object, obj1, and T1 is selected to move out of the wait set b. Another thread invokes the notifyAll method on the object c. Another thread invokes the resume method on thread T1 d. Another thread interrupts thread T1 e. The priority of thread T1 is increased f. A specified timeout period has elapsed g. Another thread invokes the join method on thread T1
The correct answers are a,b,d,f. I'm having trouble with the b). I thought that notifyAll only notifies all of the threads waiting in the pool of the object but in order to get out of the pool the thread must be chosen by the scheduler to move to the running state... Am I missing something? TIA, Bojan
when notifyAll() is invoked on an object all threads waiting on that object are made runnable, so they are now eligible to be chosen by the scheduler to go into the running state. But they will move out of the wait state. [ March 24, 2004: Message edited by: Richard Quist ]
I see, but then in order to enter the waiting pool again, all threads have to execute the .wait() method on the original object again? I mean, if they were all waiting on the same object's lock and only one of them all gets to execute, the pool will be "cleared" (i.e. all the threads will move to the runnable state) so that the rest of the threads get "discarded" - they won't wait on the object's lock no more?
That is my understanding... But - to be clear - before the threads can continue processing they will have to re-acquire the lock for the object..in other words, "wait() doesn't return until the lock is re-acquired" [ March 24, 2004: Message edited by: Richard Quist ]
No matter. Try again. Fail again. Fail better. This time, do it with this tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss