Re: Deadlock in DisplayImpl or ScalarMap?

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, 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'.