"In which of the following cases a thread will definitely be alive but not be running?"
"The thread has issued a call to wait( )."
This statement is not necessarily true. A thread would have to own the intristic lock of the object for the thread to be definitely not running after a call to wait() has been issued.
If a call to wait() is issued and the calling thread does not own the lock on the object, an exception is thrown.
About Question enthuware.ocpjp.v8.2.1505 :
Moderators: Site Manager, fjwalraven
-
- Posts: 10
- Joined: Tue Dec 01, 2015 11:22 am
- Contact:
-
- Site Admin
- Posts: 10388
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1505 :
Sure. The option has been updated to make it clear.
thank you for your feedback!
Paul.
thank you for your feedback!
Paul.
-
- Posts: 10
- Joined: Tue Dec 01, 2015 11:22 am
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1505 :
I also noticed this, just now:
"The thread is trying to enter a synchronized block and the monitor is not free."
The explanation of which is:
"In this situation, the thread will be blocked until some other thread calls notify()/notifyAll() on the object whose synchronized block this thread is trying to enter."
I find this explanation wrong and that a more correct one would be:
"In this situation, the thread will be blocked until the monitor is set free and the thread takes the monitor. If, however, more threads are also waiting for the same monitor, either one of them can take it - but not both at the same time - in which case the other thread will block until the monitor is free again."
Something along those lines, no?
"The thread is trying to enter a synchronized block and the monitor is not free."
The explanation of which is:
"In this situation, the thread will be blocked until some other thread calls notify()/notifyAll() on the object whose synchronized block this thread is trying to enter."
I find this explanation wrong and that a more correct one would be:
"In this situation, the thread will be blocked until the monitor is set free and the thread takes the monitor. If, however, more threads are also waiting for the same monitor, either one of them can take it - but not both at the same time - in which case the other thread will block until the monitor is free again."
Something along those lines, no?
-
- Site Admin
- Posts: 10388
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocpjp.v8.2.1505 :
Updated.
-Paul.
-Paul.
Who is online
Users browsing this forum: No registered users and 5 guests