Q on Dan's Mock Exam - Thread

[Reshma Shanbhag]

Hi All,
Please help with this question from Dan's mock exam on Thread's (Exam d Q.no 4)
Q:Which of the following occurs after invoking the interrupt method on a thread that is blocking due to a previous invocation of the join, sleep or wait method?
a.The thread moves into the Not-Runnable state.
b.The thread moves out of the Not-Runnable state.
c.An InterruptedException is thrown when the thread moves into the running state.
d.Calling Thread.interrupted after the InterruptedException is thrown will return true.
e. None of the above.
The answers are b & c
All i know is, interrupt works differently depending on what the thread is doing presently. When the InterruptedException is thrown it clears the interrupt flag.
When invoked interrupt() method with thread being in waiting state because of sleep() method, moves the thread from not-runnable state to runnable state throwing the Interrupted exception.
When thread is in waiting state because of wait() method, invoking the interrupt() method makes the thread move out of not-runnable state to ready state throwing the interrupted exception. This thread can get back to running state only when it is able to get a CPU cycle.
When the thread is in waiting state because of invocation of join(), it causes the thread to come out of the waiting state, throws the interrupted exception proceeding to the dead state.
If my understanding about the behavior of interrupt is right then the option
'C' is not valid as same behavior cannot be generalized for join(), sleep() and wait() with interrupt.
Plz help me with this
Reshma

[Sarma Lolla]

Reshma,

When the thread is in waiting state because of invocation of join(), it causes the thread to come out of the waiting state, throws the interrupted exception proceeding to the dead state

I can't agree with this. Once a thread A calls the join() on another thread B() thread A is blocked till thread B is dead. At this stage if thread A is interrupted then it comes out of blocking and will be in ready state. Once it gets CPU cycles it gets interrupted exception. After handling this exception it can continue with any code that is present. It doesn't necessarily die at this stage.
[ March 14, 2003: Message edited by: Sarma Lolla ]

[Dan Chisholm]

Reshma,
Thank you for using my exams.
Multithreading existed on computer platforms long before Java was developed so the Java Language Specification makes no attempt to redefine what already exists. Instead, the JLS remains flexible so that Java can be implemented on top of preexisting systems. For example, the JLS does not specify some of the basics such as the names of the thread states. Reading descriptions of thread behavior from multiple resources can be confusing because the terms used by each resource might be different. If you read about the behavior of the wait method using resource A, then it might be difficult to compare that behavior to a description of the sleep method offered by resource B.
Answer option C is as follows.
"An InterruptedException is thrown when the thread moves into the running state."
Although some authors use different names for thread states, the basic idea is as follows. If a thread is in the not-runnable state (a.k.a. blocking, sleeping, waiting, etc. state) when interrupted then it moves to the ready state (a.k.a runnable state). At the discretion of the thread scheduler it moves to the running state where it throws an InterruptedException.
Some may argue that the term not-runnable is really just a general term for more specific states such as sleeping, waiting, etc. I think it is reasonable to accept that argument. On the other hand, I don't see much difference between the terms "ready" and "runnable".

[Reshma Shanbhag]

Dan,
Thanks a ton for helping me, your explanation was extremely helpful.

Reshma

[mohamed hamdy]

When thread is in waiting state because of wait() method, invoking the interrupt() method makes the thread move out of not-runnable state to ready state throwing the interrupted exception. This thread can get back to running state only when it is able to get a CPU cycle.

i think it must also acqure the lock of the object.am i right?

[Dan Chisholm]

Originally posted by mohamed hamdy:

i think it must also acqure the lock of the object.am i right?

Yes. A thread gives up the lock when it is waiting and must reacquire the lock before it will run again.
A sleeping thread does not give up any locks so the above does not apply to a sleeping thread.