Doubt on wait() and notify(). SCJP K&B book.

[Pawel Nowacki]

Im a little bit confused after reading thread chapter on wait() and notify() methods.
There is a statement on page 752 in K&B SCJP 6 book :

"(...), when notify() is caled, that doesn't mean the thread gives up its lock at the moment. If the thread is still
completing synchronized code, the lock is not released until the thread moves out of synchronized code. So just
because notify() is called doesn't mean the lock becomes available at that moment."

And there is this question 6 on page 775:

"Assume the following method is properly synchronized and called from a thread A on an object B:
wait(2000);
After calling this method, when will the thread A become a candidate to get another turn at the CPU?
A. After object B is notified, or after two seconds
B. After the lock on B is released, or after two seconds
C. Two seconds after B is notified
D. Two seconds after lock B is released

OK: A is correct. Either of two events will make the thread a candidate for running again.
WRONG: B is incorrect because a waiting thread will not return to runnable when the lock is released, unless a notification occurs.
C in incorrect because the thread will become a candidate immediately after notification (...)"

My doubts are:

1. Given that notify() is not causing to release lock immediately how is A can be true?
2. Why B is wrong? notify() is not going to make A go until code reaches end of synchronize block that should enclose notify() call. So naturally A have his go after lock on B is released?
3. Book clarification on ansfer C is also wrong given previous statement about notify()?

thanks in advance,
Pawel

[Ankit Garg]

You are confused here. You are mixing releasing lock and getting CPU time. Lets take an example. Suppose I'm playing a video game. And you are sleeping in your bed. When I shout that I'm about to finish my game and you can play, it is like notifying. When I shout (i.e. notify you) you wake up and are willing to play a game (it is like a thread being eligible for CPU time). But I have not left the game console yet (i.e. when I notified you, I didn't release the lock on the object i.e. game console). I think this will make it a bit clear ...

[Paul Stat]

Ankit Garg wrote:You are confused here. You are mixing releasing lock and getting CPU time. Lets take an example. Suppose I'm playing a video game. And you are sleeping in your bed. When I shout that I'm about to finish my game and you can play, it is like notifying. When I shout (i.e. notify you) you wake up and are willing to play a game (it is like a thread being eligible for CPU time). But I have not left the game console yet (i.e. when I notified you, I didn't release the lock on the object i.e. game console). I think this will make it a bit clear ...

Nice analogy thanks for that

[Ankit Garg]

I think its time for a new saying

"An example a day, keeps the problems away" - Ankit

[Pawel Nowacki]

Ok, thats more clear to me now. Keeping your story style : When you shout I wake up and become a candidate to play. Then I move to the lounge (runnable state). But there I could find another people sitting, wanting to play. And when you release game pad (the lock) we start competing for it, but only Scheduler is the one to pick up one of us. Some of us could have higher game score on console (higher priority set) so you could yeld() for one of us. But thats not fair and Im sure you let go and give everybody a try

[Jesper de Jong]

Hey, that's a good analogy Ankit and Pawel, I'll remember this one!

[Bharat Mehta]

Awesome analogy from Ankit

[Ruben Soto]

I'm sorry but I disagree with this one. I think that answer A is an error for a couple of reasons. To refresh everyone's memory, here's the question and the proposed correct answer:

Question: Assume the following method is properly synchronized and called from a thread A on an object B:
wait(2000);
After calling this method, when will the thread A become a candidate to get another turn at the CPU?
Proposed answer: After object B is notified, or after two seconds.

The first problem I have with the answer is that the wording is incorrect. Object B must not be notified, thread A must be notified by code in the object's wait() method (which will probably be invoked by some other unknown thread on object B.)

The second problem is that even if another thread calls B.notify(), this won't make thread A be a candidate to get another turn at the CPU. The reason is that the thread which calls B.notify() might still hold the lock on B for an indeterminate amount of time. After that thread calls notify() on B, and before it releases the lock on B, thread A will not become Runnable, it will merely go from Waiting state to Blocking state (but it won't become Runnable, which is what it needs to be to become a candidate to get another turn at the CPU.)

I would appreciate it if someone can show me where my reasoning is not correct.

Thanks,

Ruben

EDIT: I just realized that this is a potential zombie. Administrators, feel free to move this to a new thread.