[prev in list] [next in list] [prev in thread] [next in thread] 

List:       batik-dev
Subject:    Re: Deadlock when calling RunnableQueue.setIdleRunnable
From:       Cameron McCormack <cam () mcc ! id ! au>
Date:       2006-12-20 23:34:36
Message-ID: 20061220233436.GA18288 () arc ! mcc ! id ! au
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]