Although this looks very plausible, it is actually not true. Even if you use notify(), you will often have to use a while loop rather than a simple "if" for the wait condition.leandro oliveira writes:
When to wait is a really important point, most of the times, if u have an object and many threads willing for this object's lock, if you use notifyAll() it's often used something like this:
while(!ok){
this.wait();
}
but if you use notify() the following will work:
if(!ok) wait();
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
"I'm not back." - Bill Harding, Twister
...It would not suffice here to use notify, which wakes up only one thread (if one exists). The JVM might pick a thread waiting for a condition that does not hold without picking the possibly many that could continue.
<snip>
However, in some other classes, you can reduce the context-switch overhead associated with notifications by using a single notify rather than notifyAll. Single notifications can be used to improve performance when you are sure that at most one thread needs to be woken. This applies when:
All possible waiting threads are necessarily waiting for conditions relying on the same notifications, usually the exact same condition. Each notification intrinsically enables at most a single thread to continue. Thus it would be useless to wake up others. You can accomodate uncertainties surrounding the possibility that an interrupt and a notify may occur at about the same time. In this case, the one thread that was notified is about to terminate. You might want another thread to receive notification instead, but this is not automatically arranged. (The issue does not arise with notifyAll since all threads are woken.)
<snip>
In open, extensible designs, the conditions under which notify apply are rather special and fragile. The use of notify, and optimizations of guarded constructions more generally, are common sources of error. As a general design tactic, it is a better idea to isolate uses of notify to concurrency control utility classes that can be heavily optimized and carefully reviewed and tested.
Regards,<br /> merlin_bar
"I'm not back." - Bill Harding, Twister
Regards,<br /> merlin_bar
"I'm not back." - Bill Harding, Twister
Originally posted by Jim Yingst:
Allen Holub, the other part of the holy trinity of Threading.
By which you mean Allen Holub, Doug Lea, and ??? There are a number of people who know their stuff here; I'm not sure who else is regarded as pre-eminent.
Originally posted by Jim Yingst:
I agree with Peter, with the following addendum (which is not too different from what Joe Cheng seems to have been saying):
With all due respect, I don't think a blanket recommendation in favour of notifyAll() is a good idea
I'd say that for people who still (after reading the other advice here) aren't really sure yet which is more appropriate for their situation, because they're still learning how wait/notify works or because their code has gotten too complex to tell what's going on, notifyAll() is the safer one to go with...
Don't get me started about those stupid light bulbs. |