> > Hi,
>
[quoted text clipped - 49 lines]
>
> 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()?
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)?
Eric Sosman - 27 Jun 2007 15:14 GMT
>>> Hi,
>>> I am a bit confused as how wait() actually works. I know the purpose
[quoted text clipped - 57 lines]
> 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.

Signature
Eric Sosman
esosman@acm-dot-org.invalid
Michael Jung - 27 Jun 2007 19:43 GMT
> > > Now, I understand that notifyAll() ONLY notifies other threads
> > > blocking on this object that the current thread is done with the
[quoted text clipped - 19 lines]
> > > and the rest are put on the waiting list once they "failed" the
> > > condition?
No, they come out of the wait, but halt at the next statement (1), because
they do not have the lock. They don't get to "condition" yet.
> > 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
[quoted text clipped - 6 lines]
> > executions that hold that monitor. None of them will be put back to
> > waiting on the object.
But since they are all in a synchronized block, only one can run - the one who
owns the monitor.
> 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?
No. As above, they do not wait because they do another while-iteration, but
because they are in a synchronized block and wait for the lock immediately
after the wait.
[...]
> 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)?
No. Only one executes it. Why don't you write a simple test program?
public static void main(String[] argv) {
final Object o = new Object();
Thread t1 = new Thread() {
public void run() {
synchronized (o) {
try {
o.wait();
System.out.println(this);
Thread.sleep(1000);
}
catch (InterruptedException e) {
}
}
}
};
t1.start();
Thread t2 = ... // as t1
Thread t3 = new Thread() {
public void run() {
synchronized (o) {
o.notifyAll();
}
}
};
t3.start();
}
You will see the prints come in 1s separated, your interpretation would expect
them to show up immediately.
Michael
Aria - 27 Jun 2007 20:29 GMT
Thank you guys, actually I wrote a small program to verify my
statements and along the way I learned some else too. But for some
reason the last time I posted it, it did not go through. *shrug* Again
thank you.