Re: notify() and wait()
On 1/9/2010 4:00 PM, Jack wrote:
I have two threads: thread1 and thread2 and use myObject for
synchronization.
Object myObject = new Object();
If thread1 calls myObject.notify() first, then thread2 calls
myObject.wait(). The wait() still blocks thread2, right?
Yes. If thread1 calls myObject.notify() one million times
and then thread2 calls myObject.wait(), thread2 blocks. A
notification is a one-shot deal; there's no memory of how often
or when notify() has been called. notify() just awakens some
thread that happens to be in wait() at the moment; if nobody
is waiting, nobody is awakened. Ever.
In general, it is difficult to control the timing of notify() and wait
() call. How to prevent this situation.
When wait() returns, it does not mean "There *is* something
to be done," but "There *may be* something to be done." Java,
of course, has no idea what the "something" might be, nor what
"ready to be done" requires. You, the programmer, know these
things, and you, the programmer write the appropriate tests.
So: The thread that waits doesn't just wait(), it first
checks whether there's something to do already. And after the
wait() returns, it checks *again* just in case some other thread
came along and took care of whatever it was. So (anticipating
the answer to your next question)
Thing toBeDone;
synchronized (myObject) {
while (! myObject.somethingIsReadyToBeDone())
myObject.wait();
toBeDone = myObject.removeTheReadySomething();
}
toBeDone.doWhateverItIs();
Study how this works. It synchronizes on myObject (which
is probably something more specialized than a plain Object) to
"stabilize" it so no other thread's activity will disturb things
while this thread is deciding what to do. Then it checks whether
there's something to be done. If there is, it plows straight
ahead without calling wait() at all -- there's work to be done,
so there's nothing to wait for. Otherwise it calls wait(), which
does two things: It puts the thread to sleep, and it releases
the lock on myObject so other threads can synchronize on it.
Before wait() returns, it re-acquires the lock so myObject
is once again stable. Now we re-check for readiness; an unknown
amount of time may have passed since somebody else called notify(),
and in that interval things might have changed -- so we check
again, knowing that nothing further will change while we've got
the myObject lock. If there's nothing to be done (some other
thread got there first), we loop around and wait() again.
Eventually, the test says "there's something to do," and
we escape from the while loop. Then *before* releasing the lock
we grab the "work order" or whatever from myObject, or otherwise
indicate that "we got it; nobody else need try." We do this
while still holding the lock, because if we were to let go some
other thread could jump in and mess us up. Finally, when we've
got all the information we need to carry on with our task, we
can drop the lock and go about our business.
When I call notify() and wait(), must I put them in a synchronized
block? like:
synchronized(myObject)
{
myObject.notify();
}
Yes, for both the notify() or notifyAll() and for the wait().
--
Eric Sosman
esosman@ieee-dot-org.invalid