About Question enthuware.ocpjp.v7.2.1288 :

[lucas91]

Hi Paul, I want to know, why the answer attached below is wrong? the only difference from one of the right ones is I put Thread.yield moving from Running to Runnable and no code instead of return moving to Dead state. Do the jvm uses return internally after the run method runs?

[admin]

Thread.yield() is valid. But your answer is evaluated as wrong because you have "No code required" for "Running" to "Dead", while you must somehow return from the running thread's run() method (either by return statement or by an exception) to move it to dead.

HTH,
Paul.

[lucas91]

I see, but if I don't explicitly call return and run method ends the thread goes to dead state also no?

[admin]

Yes, that would be an implicit return and the question is asking for code that could potentially cause the given state change.
But I see your point, it is not really that clear and open to multiple interpretations
-Paul.

[lucas91]

ok, I though that maybe it might have been an implicit return i missed, but yeah the question was not so clear, thanks Paul

[Danny Sheridan]

But wouldn't obj.wait() cause the thread's state to become WAITING not BLOCKED?

From the docs of java.lang.Thread.State.WAITING

A thread is in the waiting state due to calling one of the following methods:
Object.wait with no timeout
...

[admin]

It can go to blocked also. As per http://docs.oracle.com/javase/7/docs/ap ... ml#BLOCKED

public static final Thread.State BLOCKED
Thread state for a thread blocked waiting for a monitor lock. A thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling Object.wait.

HTH,
Paul.

[Danny Sheridan]

I think the docs are referring to how it can happen that a thread would be BLOCKED re-seeking an object's monitor.
I find them a bit unclear but when they say:
reenter a synchronized block/method after calling Object.wait
I believe
... and after a subsequent call to notify
is understood.
In the solution the code obj.notifyAll() causes the change of state from BLOCKED to RUNNABLE
After the obj.wait() call the state is WAITING, then if and when a notify is called it becomes BLOCKED.
The change from BLOCKED to RUNNABLE happens if and when the monitor is acquired.

[admin]

The diagram in the question is not really a chain of method calls that would take the same thread from one state to all others. It is just meant to show which methods are capable of taking a thread (some thread, not necessarily the same thread) from one state to another. From this perspective, if you call wait from a thread, it will go into blocked state as explained by the quoted JavaDoc.

HTH,
Paul.

[zhengye1]

I want to know why my answer wrong? Does because

Code: Select all

Thread.yield()

should place in Runnable <- Running ? Or

Code: Select all

run() 

in Running -> Dead?

[admin]

It is wrong because yield doesn't move a thread from Runnable to Running. It can move a thread from Running to Runnable.