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.
Hi Russell, > I am having trouble with (I think) a deadlock in DisplayImpl or > ScalarMap. Details: > > There is code in my app that adds a DataReference to a DisplayImplJ3D. > The code does this inside SwingUtilities.invokeLater() in a SwingWorker > thread: > > display.disableAction(); > display.removeAllReferences(); > for ... { > display.addReferences(renderer, dataRef, constantMaps, > constantMaps.length); > } > display.enableAction(); > > The SwingWorker thread takes care of loading the data via ADDE before > adding data to the display, so it happens in the background. > > When the display already has a number of DataReferences (about 8), I get > the app to add one more. At that point everything hangs, ie the display > stops updating (all swing components and the visad component) with no > cpu usage. > > 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. > > Now, I can keep tracing to find out what is happening in the ScalarMap, > but I thought I'd ask here to see if anyone might be able to recognise > this. Anyone? Bill? :) 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. 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'. Cheers, Bill
visad
archives: