What is the effect of issuing a wait() method on an object A. If a notify() method has already been sent to that object then it has no effect B. The object issuing the call to wait() will halt until another object sends a notify() or notifyAll() method C. An exception will be raised D. The object issuing the call to wait() will be automatically synchronized with any other objects using the receiving object.
The problem with C is that while an InterruptedException may be thrown, very often it will not be. I actually like answer B better - it's wrong because the object doesn't halt, rather the thread in which the wait() was called is what halts. But I think that's just poor phrasing on the part of the writer - I susped that he/she meant for B to be true. That's just a guess of course, but none of the answers are really true either. B or C are the best choices IMO.
For ans c) An Exception will be raised , Here the qstn talks about wait() we can't say for sure 'An Exception will be raised. What if the waiting thread is not notified at all by any other thread ? It will still be waiting right? Even in timesharing scheduler it will still be waiting because eventhough an execution slot is allocated for this thread, it still chooses to wait because it is waiting for someone to notify this thread about 'the lock for which you are waiting is available now. You run and grab it' message. So we can't say for sure InterruptedException will happen. (-This is extra info only.- The other 2 forms of wait(long millisec)/wait(long millisec,int nanosec) were used, then the waiting thread will wait maximum for the arg-specified time and goes straight to ready state. Next when this thread is scheduled to execute it may/may not execute the InterrupedException handler depending upon whether it was brought to 'ready state' by means of an interrupt()/notify()/notifyAll() OR by means of the timeout was over.) So I think b) is best answer. regds maha anna
[This message has been edited by maha anna (edited April 05, 2000).]