About Question enthuware.ocpjp.v7.2.1288 :
Moderator: admin
-
- Posts: 9
- Joined: Wed Jul 17, 2013 1:02 pm
- Contact:
About Question enthuware.ocpjp.v7.2.1288 :
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?
- Attachments
-
- my answer, only difference is the Thread.yield moving to runnable and no code moving to Dead state
- enthuware.gif (10.53 KiB) Viewed 7972 times
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
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.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 9
- Joined: Wed Jul 17, 2013 1:02 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
I see, but if I don't explicitly call return and run method ends the thread goes to dead state also no?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
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.
But I see your point, it is not really that clear and open to multiple interpretations
-Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 9
- Joined: Wed Jul 17, 2013 1:02 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
ok, I though that maybe it might have been an implicit return i missed, but yeah the question was not so clear, thanks Paul
-
- Posts: 30
- Joined: Sat May 02, 2015 4:48 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
But wouldn't obj.wait() cause the thread's state to become WAITING not BLOCKED?
From the docs of java.lang.Thread.State.WAITING
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
...
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
It can go to blocked also. As per http://docs.oracle.com/javase/7/docs/ap ... ml#BLOCKED
Paul.
HTH,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.
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 30
- Joined: Sat May 02, 2015 4:48 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
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.
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.
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
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.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 17
- Joined: Wed Jan 07, 2015 12:06 am
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
I want to know why my answer wrong? Does because should place in Runnable <- Running ? Or in Running -> Dead?
Code: Select all
Thread.yield()
Code: Select all
run()
- Attachments
-
- Vincent901201_1460346099511_89.png (13.6 KiB) Viewed 7158 times
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v7.2.1288 :
It is wrong because yield doesn't move a thread from Runnable to Running. It can move a thread from Running to Runnable.
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 28 guests