About Question com.enthuware.ets.scjp.v6.2.628 :

All the posts and topics that contain only an error report will be moved here after the error is corrected. This is to ensure that when users view a question in ETS Viewer, the "Discuss" button will not indicate the presence of a discussion that adds no value to the question.

Moderators: Site Manager, fjwalraven

Post Reply
Francisco J. Bermejo

About Question com.enthuware.ets.scjp.v6.2.628 :

Post by Francisco J. Bermejo »

You mark as correct answer this: "The thread that has called the wait() will stop executing until some other thread calls notify or notifyAll on the same object."
I think that the answer is wrong, because a thread that has called wait() is not guaranteed to change its "waiting state" back to "runnable", if other thread calls notify().
This is because (quoting K&B study guide): "An object can have many threads wating on it, and using notify() will affect only one of them. Which one, exactly, is not specified and depends on the JVM specification, so you should never rely on a particular thread being notified in preference to another."
If the answer was ""The thread that has called the wait() will stop executing until some other thread calls notifyAll on the same object." it would be correct.

admin
Site Admin
Posts: 10046
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.628 :

Post by admin »

Francisco J. Bermejo wrote:You mark as correct answer this: "The thread that has called the wait() will stop executing until some other thread calls notify or notifyAll on the same object."
I think that the answer is wrong, because a thread that has called wait() is not guaranteed to change its "waiting state" back to "runnable", if other thread calls notify().
This is because (quoting K&B study guide): "An object can have many threads wating on it, and using notify() will affect only one of them. Which one, exactly, is not specified and depends on the JVM specification, so you should never rely on a particular thread being notified in preference to another."
If the answer was ""The thread that has called the wait() will stop executing until some other thread calls notifyAll on the same object." it would be correct.
With the way you are interpreting the option, even the correction that you've suggested does not make it a correct option because "The thread that has called the wait() will stop executing until some other thread calls notifyAll on the same object." would imply that the thread will remain stopped even if another thread calls notify, which is obviously not the case because notify would work if this was the only thread waiting. So notifyAll is not the only possible way to wake it.

I think the given option is correct because it would take either a notify or notifyAll to wake the waiting thread.

-Paul.
If you like our products and services, please help us by posting your review here.

Michoel Shkolnik

Re: About Question com.enthuware.ets.scjp.v6.2.628 :

Post by Michoel Shkolnik »

I agree with Francisco that this question is confusing, but for a different reason. The answer "The thread that has called the wait() will stop executing until some other thread calls notify or notifyAll on the same object." is not correct. A thread that calls the wait() will not necessarily wait until notify() or notifyAll() is called to proceed with execution because as it is mentioned in wait()'s API doc - "interrupts and spurious wakeups are possible, and this method should always be used in a loop..". So it is technically possible that a thread will call wait() and then be interrupted before any calls to notify or notifyAll and will continue to execute (provided ofcourse that it's able to aquire a lock on the object). The correct answer should be: "The thread that has called the wait() will stop executing until some other thread calls notify or notifyAll on the same object or it is interrupted by another thread"

admin
Site Admin
Posts: 10046
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question com.enthuware.ets.scjp.v6.2.628 :

Post by admin »

You are right. A thread can come out of wait if another thread calls interrupt on the waiting thread. It still needs to reacquire the lock (just like in the case of notify/notifyAll) as the following sample code illustrates:

Code: Select all

public class ThreadTest extends Thread {

    public Object monitorObject;

    public void run() {
        synchronized (monitorObject) {
            try {
                System.out.println(this.getId() + " started running. Will call wait now...");
                monitorObject.wait();
                System.out.println(this.getId() + " started running again 1.");
            } catch (Exception e) {
                System.out.println(this.getId() + " got Excception : " + e);
                e.printStackTrace();
            }
            System.out.println(this.getId() + " started running again 2 ");
        }
    }

    public static void main(String[] args) throws Exception {

        ThreadTest tt = new ThreadTest();
        Object monitor = new Object();
        tt.monitorObject = monitor;
        tt.start();
        Thread.currentThread().sleep(1000);//to let tt acquire and release the lock on monitor
        synchronized (monitor) {
            System.out.println("Main Thread will try to interrupt tt");
            tt.interrupt();
            System.out.println("Main Thread still has the lock");
            Thread.sleep(10000);// Main thread is not releasing the lock just yet.
            System.out.println("Main Thread releasing the lock now");
        }
    }
}
The option has now been updated.

thank you for your feedback!
If you like our products and services, please help us by posting your review here.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 49 guests