On 27 Nov, 23:18, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
Some of those awakenings may be "genuine" in the sense that notify()
was truly called, but "spurious" in the sense that the condition
being waited for does not yet hold.
This is what I did not fully appreciate until I found it documented on
sun's web site, for all forms of wait(), not just the ones with a
timeout parameter.
Summary: Always use
synchronized(thing) {
while (! readyToGo())
thing.wait();
doLockedThings(thing);
}
doOtherThings(thing);
... because it will always be safe, no matter what happens.
I will do this. But there is still something I don't quite understand.
If the readyToGo() method is also synchronized on 'thing' (which it is
in my case) then I dont need to call readyToGo, do I? I could access
the private member directly. Another thread cannot access the variable
because I am already synchronized via the line "synchronized(thing)",
right?
In any case it is *never* correct to write
synchronized(thing) {
thing.wait(); // unguarded wait is R-O-N-G!
doLockedThings(thing);
}
doOtherThings(thing);
This is what I was doing. I will fix it.
<http://virtualinfinity.net/wordpress/technical-book-recommendations/java-concurrency-in-practice/>