wait vs. notify

[Vicken Karaoghlanian]

the thread that calls wait automatically releases that object's lock flag.

when a notify call is executed on a particular object, an arbitrary thread is moved from that object's wait pool to a lock pool where threads stay until the object's lock flag becomes available.

Howcome notify is waiting for the lock that is already released by wait???!!!

[Ernest Friedman-Hill]

You have to have to lock on an object to call notify -- i.e.,
synchronized (someObject) {
someObject.notify();
}
Now, think about it. The threads that are awoken by notify() can't get the lock until this synchronized block release it. See? Because you can't call notify() unless you're actually holding the lock on the object.
Now when you call wait(), you also have to have the lock. When you call wait(), it gives up the lock. Then when someone calls notify(), this thread may then reaquire the lock and wait() can return. wait() can't return until it has the lock.
[ July 27, 2003: Message edited by: Ernest Friedman-Hill ]

[Anupam Sinha]

Hi Ernest
Why doesn't wait returns until it reacquires a lock. As far as I think this would cause extra overheads as the thread in some cases would just acquire a lock to release it without doing much.
Or does it do something. Am i missing something here.

[Alton Hernandez]

Originally posted by Anupam Sinha:
Hi Ernest
Why doesn't wait returns until it reacquires a lock.

Hi Anupam,
I think the JLS clearly specified the reason why:

JLS 17.14
..on return from the wait method, the state of the object s lock is exactly as it was when the wait method was invoked.

Hope this helps.
[ July 27, 2003: Message edited by: Alton Hernandez ]

[Anupam Sinha]

Hi Alton
Thanks for the research that you did for my question but my intention of asking the question was, why does a thread needs to acquire a lock when it may be very clear that the only thing that the thread will do with the lock after acquiring is release it.
consider this code

synchronized(aobj)             // line 1
{                              // line 2
    wait();                    // line 3
}                              // line 4

At line 3 the lock will be released which was obtained at line 1. Now again at line 3 the lock will be obtained and on line 3 or line 4(don't know) the lock will again be released. What's the reason for this approach.

[Marlene Miller]

When a thread invokes wait on an object, the thread is added to the wait set of the object. The reason wait must acquire the lock of the object has to do with the way wait sets interact with locks (from Concurrent Programming in Java 3.2.2, Doug Lea).
I think the details are explained in Foundations of Multithreaded, Parallel, and Distributed Programming, Gregory Andrews, Chapter 5 Monitors. Here
The essential point might be that pausing a thread and releasing a lock must be atomic. Otherwise there would be a race hazard. A notification could happen after the lock is released but before the thread is suspeneded (from The Java Programming Language 10.4, Arnold, Gosling & Holmes).
[ July 27, 2003: Message edited by: Marlene Miller ]

[Alton Hernandez]

Originally posted by Anupam Sinha:
.. why does a thread needs to acquire a lock when it may be very clear that the only thing that the thread will do with the lock after acquiring is release it.

Hi Anupam,
Yes, in the sample code you provided, it appears that there is no point in acquiring the lock only to release it immediately. But in real situation, some work will be done after the wait() call which would require an exclusive use of the object.
[ July 27, 2003: Message edited by: Alton Hernandez ]

[Marlene Miller]

Conservative check-and-act methods refuse to proceed unless preconditions hold. When preconditions do hold, the action always succeeds.
There is a standard coding idiom for expressing guarded methods.
synchronized (lock) {
while (condition) wait();
//Then do what must be done when the condition is true.
}
Everything is executed within synchronized code. If it were not, the state of the object would not be stable. There would be no guarantee that the condition remained true because another thread may have changed the situation that the condition tests.
(credits: The Java Programming Language & Concurrent Programming in Java)