🚀 go-pugleaf

In article <7gdrkh$ro224@forums.borland.com>, mlong@ecst.csuchico.edu 
says...
> When a thread gets exclusive access to a synchronized "monitor" method, and
> that monitor cannot complete, for whaterver reason, the request of the
> thread, the thread is put to sleep by a call to wait().  If many threads
> have been put to sleep, they are put into a waiting queue.  notify() wakes a
> randomly chosen thread.  If something happens where that thread cannot
> proceed the system can deadlock.  notifyAll() wakes all waiting threads and
> if one cannot proceed, all the others are waiting execute.  Simple rule of
> thumb that I use, and that is presented in Core Java, is to ensure that
> every wait() is matched up with a notifyAll() which seems to work well for
> me.  Of course, if you are positive that all waiting threads are capable of
> completing then this is all academic and notify() is fine.
> 
> Check out Core Java, Volume II, page 107.
> 
> Tad Frysinger wrote in message ...
> >In article <7g65lk$ksf4@forums.borland.com>, mlong@ecst.csuchico.edu
> >says...
> >> Just an addendum to what Chris said on this subject.  It is not really
> >> advisable to us notify(), it can lead to deadlocks if no thread is ready
> to
> >> activate.  notifyAll() notify's all threads that the action has
> completed.
> >> For what it's worth.
> >>
> >I'm interested in this - how can this lead to deadlocks?
> >
> >Tad Frysinger (TeamB)
> 
> 
> 
Ah..  I misunderstood.  I was trying to figure out in a scenario in which 
I had a single thread I was waking up with a call to notify() how this 
might be an issue.

You bring up an interesting point where multiple threads are concerned, 
however...

Tad Frysinger (TeamB)