Hi thomas, thread-sync stuff can give lots of fun and excitement - one can find problems weeks and months later...
The RunnableQueue/UpdateManager-duo would be a nice playground for pathfinder, which was designed to systematically analyse threading problems. Can there be more than one instance of an UpdateManager? For cameron's deadlock-problem i would propose to drop synchronized from setIdleRunnable() and make the other involved members list, idleRunnable and idleRunnableWaitTime private, so that nobody can bypass the synchronization (on list) as it is now. greetings dieter ----- Original Message ----- From: [EMAIL PROTECTED] To: [email protected] Cc: [email protected] Sent: Wednesday, December 20, 2006 12:10 PM Subject: Re: Deadlock when calling RunnableQueue.setIdleRunnable Hi Dieter, Cameron, "Dieter von Holten" <[EMAIL PROTECTED]> wrote on 12/20/2006 04:40:14 AM: > i think it is safe to remove synchronized from setIdleRunnable(). I agree this is safe, but one needs to be careful... > setIdleRunnable() doesnt need to be synchd (on RunnableQueue) because it > operates just on list, > which is locally synchronized. 'setIdleRunnable' also adjusts the 'idleRunnable' and 'idleRunnableWaitTime' members of the RunnableQueue. Now it just so happens that all accesses to these members are inside a synchronize block on the 'list' as well so we can move exclusive access permissions to the 'list' from the more normal host object. You need to be particularly careful when dealing with java longs (which idleRunnableWaitTime is, although it may not need to be) since on many (most?) machines a long can not be written atomically (not that I like to depend on atomic read/write for concurrency control). > For my taste, there are too many synchronized methods > (setRunHandler..runnableInvoked). > Its difficult to follow the interaction between RunnableQueue and > UpdateManager... I agree this is difficult, but the two need to work in close cooperation. In particular the pause and resume of the runnable queue used to have race conditions which I think have been eliminated in the current version. If you have ideas to simplify the interaction I'm all ears. > ----- Original Message ----- > From: "Cameron McCormack" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, December 20, 2006 8:36 AM > Subject: Deadlock when calling RunnableQueue.setIdleRunnable > > > > Hi. > > > > I’ve come across a deadlock when the SVGAnimationEngine class calls > > RunnableQueue.setIdleRunnable to start the animation ticking, while at > > the same time the RunnableQueue is suspended: > > > > Found one Java-level deadlock: > > ============================= > > "Thread-1149": > > waiting to lock monitor 0x080bb9d8 (object 0xa1cc1b20, a > org.apache.batik.util.RunnableQueue), > > which is held by "RunnableQueue-26" > > "RunnableQueue-26": > > waiting to lock monitor 0x080bbb68 (object 0xa1cc1a28, a > org.apache.batik.bridge.UpdateManager), > > which is held by "Thread-1149" > > > > Java stack information for the threads listed above: > > =================================================== > > "Thread-1149": > > at > org.apache.batik.util.RunnableQueue.setIdleRunnable(RunnableQueue.java:494) > > - waiting to lock <0xa1cc1b20> (a > org.apache.batik.util.RunnableQueue) > > at > org.apache.batik.bridge.SVGAnimationEngine.start(SVGAnimationEngine.java:428 > ) > > at > org.apache.batik.bridge.BaseScriptingEnvironment.dispatchSVGLoadEvent(BaseSc > riptingEnvironment.java:550) > > at > org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(UpdateManager.jav > a:239) > > at > org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(UpdateManager.jav > a:220) > > - locked <0xa1cc1a28> (a org.apache.batik.bridge.UpdateManager) > > at > org.apache.batik.swing.svg.SVGLoadEventDispatcher.run(SVGLoadEventDispatcher > .java:100) > > "RunnableQueue-26": > > at > org.apache.batik.bridge.UpdateManager$UpdateManagerRunHander.executionSuspen > ded(UpdateManager.java:877) > > - waiting to lock <0xa1cc1a28> (a > org.apache.batik.bridge.UpdateManager) > > at > org.apache.batik.util.RunnableQueue.executionSuspended(RunnableQueue.java:50 > 8) > > - locked <0xa1cc1b20> (a org.apache.batik.util.RunnableQueue) > > at > org.apache.batik.util.RunnableQueue.run(RunnableQueue.java:167) > > at java.lang.Thread.run(Thread.java:619) > > > > I’m not so good at threading issues: what’s the correct solution? Does > > RunnableQueue.setIdleRunnable really need to be synchronized? > > > > Thanks, > > > > Cameron > > > > -- > > Cameron McCormack, http://mcc.id.au/ > > xmpp:[EMAIL PROTECTED] ▪ ICQ 26955922 ▪ MSN [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
