You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Cameron McCormack <ca...@mcc.id.au> on 2006/12/20 08:36:57 UTC
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(BaseScriptingEnvironment.java:550)
at org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(UpdateManager.java:239)
at org.apache.batik.bridge.UpdateManager.dispatchSVGLoadEvent(UpdateManager.java: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.executionSuspended(UpdateManager.java:877)
- waiting to lock <0xa1cc1a28> (a org.apache.batik.bridge.UpdateManager)
at org.apache.batik.util.RunnableQueue.executionSuspended(RunnableQueue.java:508)
- 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: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
Re: Deadlock when calling RunnableQueue.setIdleRunnable
Posted by Cameron McCormack <ca...@mcc.id.au>.
Dieter von Holten:
> 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?
There’s just one instance of an UpdateManager per document, and one
RunnableQueue for the 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.
Ok I’ll remove the synchronized from the method. Making idleRunnable
and idleRunnableWaitTime private makes sense, and I don’t think
RunnableQueue is really designed to be subclassed (although I always
prefer to leave things as protected unless there’s a good reason, to
make subclassing easier). Making list private doesn’t seem as useful
though, since there’s the getIteratorLock method, which returns the
list. It’s used in places like AbstractJSVGComponent to mess with the
RunnableQueue’s contents.
--
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
Re: Deadlock when calling RunnableQueue.setIdleRunnable
Posted by Dieter von Holten <in...@dvholten.de>.
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: thomas.deweese@kodak.com
To: batik-dev@xmlgraphics.apache.org
Cc: batik-dev@xmlgraphics.apache.org
Sent: Wednesday, December 20, 2006 12:10 PM
Subject: Re: Deadlock when calling RunnableQueue.setIdleRunnable
Hi Dieter, Cameron,
"Dieter von Holten" <in...@dvholten.de> 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" <ca...@mcc.id.au>
> To: <ba...@xmlgraphics.apache.org>
> 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: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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>
Re: Deadlock when calling RunnableQueue.setIdleRunnable
Posted by th...@kodak.com.
Hi Dieter, Cameron,
"Dieter von Holten" <in...@dvholten.de> 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" <ca...@mcc.id.au>
> To: <ba...@xmlgraphics.apache.org>
> 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: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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
>
Re: Deadlock when calling RunnableQueue.setIdleRunnable
Posted by Dieter von Holten <in...@dvholten.de>.
hi cameron,
i think it is safe to remove synchronized from setIdleRunnable().
For my taste, there are too many synchronized methods
(setRunHandler..runnableInvoked).
Its difficult to follow the interaction between RunnableQueue and
UpdateManager...
setIdleRunnable() doesnt need to be synchd (on RunnableQueue) because it
operates just on list,
which is locally synchronized.
greetings
dieter
----- Original Message -----
From: "Cameron McCormack" <ca...@mcc.id.au>
To: <ba...@xmlgraphics.apache.org>
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: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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org