Interrupt method + volatile modifier?

[Marx Villegas]

Hi amigos,
I have a tiny question. Are the volatile modifier and the interrupt method appearing in the exam?
Gracias in advance...
Marx

[Deepak Bala]

Yes, both of them appear on the exam. I am talking about SCJP 1.5 I dont know about the 1.4 version

[J Sato]

Can anyone provide more detail on what we need to know regarding interrupt()? I do not recall reading about it in the K&B book. If it's there and I just missed it, if someone could point that out too I'd appreciate it.

Thanks.

[Edisandro Bessa]

Hi Sato,

The following question is from WhizLabs. Such question covers the interrupt() method.

Please try to answer it by yourself. I will provide the correct answer later.

Given the following run method of a thread, which are the ways in which a thread will surely come out of the waiting state ? (Choose all that apply)

public void run(){
    synchronized(this){
        try{
            wait(5000);
        }
        catch(InterruptedException ie){}
    }
}

a) Another thread which owns the lock of the object invokes notify();

b) Another thread which owns the lock of the object invokes notifyAll();

c) Compilation fails.

d) The time period of 5 seconds has elapsed.

e) Another thread invokes join() on the thread.

f) Another thread invokes interrupt() on the thread.

g) Another thread invokes resume() on the thread.

h) An exception is thrown at runtime.
[ April 17, 2006: Message edited by: Edisandro Bessa ]

[Amirr Rafique]

Hi Edisandro

Given the following run method of a thread, which are the ways in which a thread will surely come out of the waiting state ? (Choose all that apply)

code:
--------------------------------------------------------------------------------

public void run(){ synchronized(this){ try{ wait(5000); } catch(InterruptedException ie){} }}

--------------------------------------------------------------------------------



a) Another thread which owns the lock of the object invokes notify();

b) Another thread which owns the lock of the object invokes notifyAll();

c) Compilation fails.

d) The time period of 5 seconds has elapsed.

e) Another thread invokes join() on the thread.

f) Another thread invokes interrupt() on the thread.

g) Another thread invokes resume() on the thread.

h) An exception is thrown at runtime.

I think answer would be b,d and f.

Please confirm

Thanks

[Shaliey Gowtham]

a, b, d, f are the possible answers

[Olivier Croisier]

I have a question about that...
I think answer A is wrong, because notify() only notifies ONE OF the waiting threads (as opposed to notifyAll()), and that lucky thread is not guaranteed to be ours. So I think notify() is not a mean to get our thread to "surely come out of the waiting state".
Or did I miss something ?

[Abhijit Sontakey]

Hi,
I think the answers are d and f.
Read the question carefully. The question is which thread will surely ...

Even if notify() is invoked on an object, a thead in waiting state to acquire monitor will not get object monitor unless the thread that invoked notify() has finished execution and the current thread has been selected to acquire lock. Hence the correct answer is d and f. Let me know if this helps.

Regards
Abhijit

[gutta rahul]

I would go with B, D and F due to following reasons.

1) Some other thread invokes the notify() method for this object and thread happens to be arbitrarily chosen as the thread to be awakened.
2) Some other thread invokes the notifyAll method for this object.
3) Some other thread interrupts thread T.
4) 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.

from 1) we can't say the thread will be the same one which is in waiting state will be notified so answer A will go down.

[Edisandro Bessa]

The correct answers are : B, D, F.

When notify() is invoked by a thread which is the owner of the lock, it will bring the one of the waiting threads out of the wait state. There's no way to predict which thread will be chosen. So choice A will not ensure that a thread will come out of the waiting state.

When notifyAll() is invoked, all the waiting threads will come out from the wait state and go for runnable state.

Abhiji has highlighted a very interesting question :

Read the question carefully. The question is which thread will surely ...

Even if notify() is invoked on an object, a thead in waiting state to acquire monitor will not get object monitor unless the thread that invoked notify() has finished execution and the current thread has been selected to acquire lock. Hence the correct answer is d and f. Let me know if this helps.

I think you missed this choice because you thought the term "surely come out" would implicitly put the thread in the running state.

But this choice is correct because even the waiting thread could not be able to get the lock, it still will leave the waiting state and enter in the runnable state.

The same analysis is also valid for wait(5000) call. Surely after at least 5 seconds has elapsed the thread will leave the waiting state and enter in either running or runnable state.

Be carefull when asked about wait() method. Here, the wait(5000) call assures that AT LEAST five seconds has elapsed and not exactly five seconds. It's a minimum value not a maximum.

The join() method causes the current thread to stop executing till the thread it joins with completes, but it does not cause it to come out the waiting state. If interrupt() is invoked on a waiting thread, InterruptedException is thrown and the thread comes out of the waiting state.

Choices C and H are ridiculous. The code compiles and runs fine.