Re: Understanding java.lang.Object.wait()
Aria wrote:
On Jun 27, 1:21 am, Owen Jacobson <angrybald...@gmail.com> wrote:
On Jun 26, 7:01 pm, Aria <maps.this.addr...@gmail.com> wrote:
Hi,
I am a bit confused as how wait() actually works. I know the purpose
of this method but what I wanted to know is when a few threads waiting
on a certain object lock and they are signaled via notifyAll(), how
does one of the threads on the waiting list for that object lock gets
the lock and what would happen to the other threads?
The other threads wait for the first thread to release the lock, and
then one of them wins it. This repeats until all of the threads have
been resumed, exactly like any other lock contention scenario.
Now, I understand that notifyAll() ONLY notifies other threads
blocking on this object that the current thread is done with the
object is "ready" to release the lock. That is the actual release of
the lock occurs AFTER the code is out of synchronized block.
Having said that, what exactly happens when the waiting threads
receive such notification? That is:
// Other threads running block
public void run() {
synchronized (obj) {
while (some condition not being met) {
try {
obj.wait();
// (1)
} catch (InterruptedException ie) { }
// Some code to process
}
}
}
When "ALL THE THREADS" receive such signal, do they all "get out" of
wait() method and then whoever wins the contention would gets the lock
and the rest are put on the waiting list once they "failed" the
condition?
It's a little hard to interpret this, but it sounds right.
When you call notifyAll on an object, every thread that's wait()ing on
that object resumes and tries to reaquire the monitors they held,
blocking if necessary until another thread releases those monitors.
The contract for a monitor is that at most one thread can hold it at a
time; this is enforced by the JVM.
If several threads that held the same monitor are awoken at the same
time, they will run "one at a time" through the parts of their
executions that hold that monitor. None of them will be put back to
waiting on the object.
Owen
So according to your statement, every time blocking threads are
signaled, ALL of them gets out of obj.wait(), "try" to acquire the
lock on the object, and only one would prevail. Which brings us to the
question I asked, they ALL get to their line (1) after each
notification and only put on the waiting list due to the while
(condition not being met). Is that a correct interpretation?
If that is the case, this would be a bit of waste of effort on JVM
part because this concludes that after each notification, JVM needs to
move all the blocking threads out of the waiting list, choose one as
the winner, let the rest go through their while loop and put on the
waiting list again. couldn't the scheduler select one thread, give it
a lock and "keep" the rest on the waiting list without getting them
ALL out of wait()?
It's not the JVM's fault that you called notifyAll()
if notify() would have sufficed ...
So my question pretty much boils down to this: When a notification
occurs, do ALL waiting threads execute line [b](1)[/b] regardless of
whether win the contention and only to be put back on the waiting list
after failing the while (condition not being met)?
If you use notifyAll(), then all the threads that are
in wait() on that obj will awaken and will compete for obj's
lock. There may also be other threads that are not in wait()
but are competing for that same lock. Assuming the current
holder of the lock eventually releases it, some other thread
will acquire it. There's no telling which of the competing
threads might win; it might even be a Johnny-come-lately that
was neither waiting nor blocked at the moment of notifyAll(),
but just happened along at a fortuitous instant.
Anyhow, some thread will acquire the lock and will do
whatever it does. If it's in the synchronized block above,
it will either dive back into obj.wait() or it will find
the condition satisfied and exit the while loop and then
the synchronized block. Either way, it releases obj's lock,
and then all the threads that still want the lock start
jumping up and down, waving their hands in the air, and
shouting "Me! Me! Pick me!" until one of them (or yet another
Johnny-come-lately) gets it. And so on, and so on, until
everybody has either gone back into obj.wait() or left the
block and gone on to do something else.
If you use notify() instead of notifyAll() the scenario
is pretty much the same, except that only one thread will
be awakened from obj.wait() (or zero, if no thread is waiting).
You still have the Johnny-come-latelies and so on, which is why
the awakened thread must re-test its predicate: the awakening
tells the thread that somebody thought something interesting
*might* have happened (which may turn out to be wrong if the
thread is waiting for a compound condition), and even if the
interesting thing *was* true for a moment it may have ceased to
be true by the time the awakened thread re-acquires the lock.
--
Eric Sosman
esosman@acm-dot-org.invalid