Thread synchronization problem

[Cameron McCormack <ca...@mcc.id.au>]

While having a look at the one memory leak regard currently reports, I
came across an unrelated threading problem.  It can be triggered (at
least on my computer) by setting the animation rate limiting mode to
Unlimited, and then opening a simple document with animation, e.g.:

  <svg xmlns="http://www.w3.org/2000/svg" width="400" height="300">
    <circle id="something" cx="50" cy="50" r="50">
      <animate attributeName="r" begin="0s" dur="5s" values="50; 0; 50"
               repeatDur="indefinite"/>
    </circle>
  </svg>

While the animation is running, press Ctrl+W to close the window.  The
interface then hangs.  Pressing Ctrl+\ shows me the two threads that are
effectively deadlocked:

  "RunnableQueue-0" daemon prio=1 tid=0x081ae770 nid=0x62ea in Object.wait() [0xb09c6000..0xb09c7140]
          at java.lang.Object.wait(Native Method)
          at java.lang.Object.wait(Object.java:474)
          at java.awt.EventQueue.invokeAndWait(EventQueue.java:846)
          - locked <0x6ca13778> (a java.awt.EventQueue$1AWTInvocationLock)
          at org.apache.batik.swing.svg.AbstractJSVGComponent$SVGListener.updateCompleted(AbstractJSVGComponent.java:1969)
          at org.apache.batik.bridge.UpdateManager$9.dispatch(UpdateManager.java:826)
          at org.apache.batik.util.EventDispatcher.dispatchEvent(EventDispatcher.java:103)
          at org.apache.batik.util.EventDispatcher.fireEvent(EventDispatcher.java:87)
          at org.apache.batik.bridge.UpdateManager.fireEvent(UpdateManager.java:755)
          at org.apache.batik.bridge.UpdateManager.updateRendering(UpdateManager.java:514)
          at org.apache.batik.bridge.UpdateManager.repaint(UpdateManager.java:571)
          at org.apache.batik.bridge.UpdateManager$UpdateManagerRunHander.runnableInvoked(UpdateManager.java:869)
          at org.apache.batik.util.RunnableQueue.runnableInvoked(RunnableQueue.java:543)
          - locked <0x6f57bc30> (a org.apache.batik.util.RunnableQueue)
          at org.apache.batik.util.RunnableQueue.run(RunnableQueue.java:251)
          at java.lang.Thread.run(Thread.java:595)
  
  "AWT-EventQueue-0" prio=1 tid=0x08548718 nid=0x62e1 waiting for monitor entry [0xb10af000..0xb10afec0]
          at org.apache.batik.bridge.UpdateManager.interrupt(UpdateManager.java:384)
          - waiting to lock <0x6f57bc30> (a org.apache.batik.util.RunnableQueue)
          - locked <0x6f57e9e0> (a org.apache.batik.bridge.UpdateManager)
          at org.apache.batik.swing.svg.AbstractJSVGComponent.stopProcessing(AbstractJSVGComponent.java:574)
          at org.apache.batik.apps.svgbrowser.Main.closeJSVGViewerFrame(Main.java:700)
          at org.apache.batik.apps.svgbrowser.JSVGViewerFrame$CloseAction.actionPerformed(JSVGViewerFrame.java:1362)
          at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
          ...
          at javax.swing.JComponent.processKeyEvent(JComponent.java:2726)
          ...
          at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

So each time a rendering update is completed, the UpdateManagerRunHander
is sent to the RunnableQueue, which locks on the RunnableQueue.  The
JSVGComponent’s updateCompleted listener calls EventQueue.invokeAndWait,
locking on the AWT thread.  Meanwhile, the AWT thread is already midway
through processing the Ctrl+W to close the window.  But
UpdateManager.interrupt synchronizes on the RunnableQueue, so the AWT
thread lock is never released.

Threading issues aren’t my forte.  How should we avoid this?

-- 
Cameron McCormack, http://mcc.id.au/
	xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org