About Question enthuware.ocpjp.v7.2.1099 :

[sinapse]

Are you sure that if some other thread calls this thread's interrupt method, the thread goes in BLOCKED state ?

[admin]

Yes, if the control remains within the synchronized block after the InterruptedException. For example, in the following code:

Code: Select all

public void run() {
            synchronized (lock) {
                try {
                    lock.wait();
                } catch (Exception e) // InterruptedException will be caught here
                  e.printStackTrace();
                }
            }

}

The catch is still within synchronized block, so it has to reacquire the lock.

HTH,
Paul

[rvdberg]

about the option
'An exception might be raised if it is not called in a synchronized block otherwise no exception will be raised.'
-It will ALWAYS raise IllegalMonitorStateException if not called in a synchronized block for that object.

I don't get it by taking question enthuware.ocpjp.v7.2.1225 into consideration.
Question: What happens when a method calls wait() without ensuring that the current thread owns the monitor of the object?
Correct answer:An IllegalMonitorStateException will be thrown if current thread does not have the monitor of the object .
While the explanation from an incorrect answer 'An IllegalMonitorStateException will be thrown whenever the method is called.' explicitely states:
"It may not throw the exception if it owns the monitor. (Note that it says 'without ensuring' )".

That sounds like whenever you don't call it from a synchronized context it might have the monitor and run correctly, or it doesn't have the monitor and throws an exception.
This questions implies that it will always throw the exception.

Am i misinterpreting something here?

[rvdberg]

Nevermind, i think i misunderstood the explanation of that question. I thought 'without ensuring' meant not putting it in synchronized context, however, now I think it meant 'not checking if it is in synchronized context'.

[StShadow]

Okay, so here I don't agree.

The answer from question:

The thread that has called the wait() will not come out of WAITING state until some other thread calls notify or notifyAll on the same object or interrupts the thread.

In fact, according to JLS 17.2.1:

An internal action by the implementation. Implementations are permitted, although not encouraged, to perform "spurious wake-ups", that is, to remove threads from wait sets and thus enable resumption without explicit instructions to do so.

So
The thread that has called the wait() might come out of WAITING state even if no other thread calls notify or notifyAll on the same object or interrupts the thread.

By the way, that's why highly recommended to call wait within loop on some logical condition to avoid spurious wake-ups, if not needed.

Or am I missing something?

[ThufirHawat]

I think the answer is wrong because the other thread must call notify() or notifyAll() and also LEAVE the synchronized block to other thread who had waiting can run again

[admin]

No, the given answer is correct. The waiting thread(s) comes out the the WAIT state as soon as another thread calls the notify(notifyAll) method. If, however, the lock is not available (i.e. until the thread that has called notify doesn't come out of the synchronized block), the thread(s) that was waiting enters the BLOCKED state. It is not "waiting" anymore. Option 1 is talking only about the WAITING state not the RUNNABLE state.

HTH,
Paul.

[jagoneye]

I don't know but I am not getting any notifications or a message if I reply or post in any thread related to OCP 7. That aside, after so long I finally see a StackOverFlow link!Thumbs up for that and this is one of the many annoying questions where I got it wrong because of english! Didn't see the might be raised else I was clearly gonna select the first option! Tricky question for me.
Edit:How come the thread comes out of waiting state if it is interrupted? Can you explain that?