NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On Fri, Jul 04, 2003 at 09:12:18AM -0500, Bill Hibbard wrote: ... > > By tracing with the universal debugging tool (System.out.println()) I > > can see that one VisAD thread is in ActionImpl.run(), synchronized on > > lockEnabled, and an AWT thread (presumably from > > SwingUtilities.invokeLater()) is waiting to synchronize in the same > > place. The VisAD thread does not leave the synchronized block, it gets > > to DisplayRenderer.prepareAction(), calls map.setRange(shadow) where map > > is a ScalarMap (Time->DisplayAnimation) and hangs there. ... > I can't find any deadlock by inspection. ScalarMap.setRange() for > a ScalarMap (Time->DisplayAnimation) calls AnimationControl.setSet(), > which calls AnimationSetControl.setSet(), which calls > Control.changeControl(), which does 'synchronized (ListenerVector)', > but it hard to see how your code in the AWT Thread can be holding > a lock on ListenerVector in Control. Found it. We have a class elsewhere in the app that implements ControlListener, and listens to AnimationControl events. That class updates swing components with invokeAndWait(). So we have a swing thread wanting to do VisAD stuff and a VisAD thread wanting to do swing stuff. Deadlock. Now I have to think about some redesign in there. > A very good way to find deadlocks is to run under jdb. When it hangs, > do a 'suspend all' and then a 'where all', which will dump the call > stack for all Threads. You should be able to spot the deadlock by > examining the locks held by the two hung Threads. I'd be happy to > take a look at the output of 'where all'. Thanks for this advice, Bill. jdb showed me exactly what was going on. Russell -- Russell Steicke -- Fortune says: Freedom from incrustation of grime is contiguous to rectitude.
visad
archives: