Wait with timeout

[adithya narayan]

Hello,

In the following question:

1)Assume the following method is properly synchronized and called from a thread A on and object B:

wait(2000);

After calling this method, when will the thread A become a candidate to get another turn at the CPU ?

A.After object B is notified, or after two seconds
B. After the lock on B is released, or after two seconds.
C.Two seconds after object B is notified.
C.Two seconds after lock B is released.


Answer : My answer went for 'B' because lets say after 2 seconds the thread stops waiting (because it wasn't notified) it cannot acquire the lock immediately unless A releases it right ? In case of

wait();

this is the expected behavior .Please correct me if i am wrong.


Thanks,
Adithya.

[Ninad Kulkarni]

I would say Option A

[adithya narayan]

..The answer is 'A' but i want to know why 'A' and not 'B' .

[K Abhijit]

Ans A is correct

The Thread A would be placed in READY queue if
1. Any other thread invokes notify on B OR
2. after time interval passed to wait methods gets lapsed.. (here it 2 secs)

Ans B should not be correct as LOCK on B has nothing to with Eligibility of A to get placed in ready queue, since we have invoked wait (A is not BLOCKED for any I/O operations)

[adithya narayan]

Lets say i had invoked

wait();

and not

wait(2000);

then it would have had to wait until the lock would have been released by thread B (even after thread B had send the notification thread A needs to acquire the lock).

But my doubt is : Doesn't 'A' need to wait for the lock held by 'B' if it is calling wait with some timeout i.e. does it automatically get the lock after the timeout ?


Thanks,
Adithya.

[Stephan van Hulst]

The thread will have to wait until it is notified or 2 seconds pass; and after either of these two events happens it will have to wait until it reacquires the lock on whatever object it's synchronized on. Only then does it continue.

I guess the answer of the question depends on what is meant by "candidate". If waiting for the object monitor is seen as being a "candidate", then answer A is correct.

The question is ambiguous though.

[K Abhijit]

This is what Oracle (sounds odd right , but still its a fact ) defines for wait(long) method

http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Object.html#wait(long)


Thread T becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:

•Some other thread invokes the notify method for this object and thread T happens to be arbitrarily chosen as the thread to be awakened.
•Some other thread invokes the notifyAll method for this object.
•Some other thread interrupts thread T.
•The specified amount of real time has elapsed, more or less. If timeout is zero, however, then real time is not taken into consideration and the thread simply waits until notified.

So what I can see here, if the specified time (should be > 0 ) lapsed then Thread becomes eligible for scheduling purposes

the question is "After calling this method, when will the thread A become a candidate to get another turn at the CPU ?"
it is not asking when Thread A would be RUNNING state, so correct answer is A, I don't see any ambiguity

[Rajesh Nagaraju]

wait(2000);

Notify or after two seconds time interval, the thread will be changed from the wait state to runnable state. This is only the guaranteed result, in option B the lock might be released by another thread within 2 seconds this does not change the state of the current waiting thread