Hi Thomas,
thanks for your reply.
My replies are in-line below...
Brian
On Mon, 2003-06-16 at 20:58, Thomas DeWeese wrote:
> Hi Brian,
>
> Brian Modra wrote:
>
> >Batik crashes when updating due to concurrent modification exceptions
> >in Sun's HashMap class. Rather than describe this in detail (it happens
> >in a number of different sequences of events) I think its enough to say
> >that the exceptions are thrown as a result of AWT thread doing a resize,
> >at the same time as batik's queue is processing something queued by
> >invokeLater. Both threads cause an SVG document update, which sometimes
> >causes the concurrent modification exception in the hash map.
> >
> This is very interesting, first a few question:
> What version of Batik are you working with?
> What hash map?
batik-src-1.5beta5.zip
j2sdk-1_4_1_02-fcs-linux-i586.rpm
- I did a gloabal search and replace of "HashTable" and import
org.apache.batik.dom.util.HashTable - with my HashMap class.
- I modified org.apache.batik.dom.util.HashTableStack class to use my
HashMap.
- Then I did a global search and replace of "import java.util.HashMap;"
with mine, and took all the "import java.util.*:" apart and did explicit
imports of all the classes needed.
>
> I agree that this is a potentially serious issue, however I have not
> seen widespread
> crashes in hash map,
Sun's HashMap isn't buggy, its not thread safe (I think they make no
claims to it being thread safe.) If you use a library class which isn't
thread safe, in a threaded environment - the only safe way is to wrap
each call:
synchronized (blah) { hashmap.whatever(...) .. }
... which then gives rise to a very good chance of thread contention
blockages.
> although I don't generally resize the document
> heavily (I don't use
> an 'opaque' resize window manager for example). I'm especially
> concerned about this
> as generally synchronization in Batik is not done through thread safe
> classes etc, but by
> using thread level/Runnables synchronization. So your suggestion is
> likely masking the
> real issue: someone doing something in an improper thread (like
> modifying AWT from the
> Update thread or the DOM from the AWT thread) .
You are right... but with these fixes, it does not crash.
In such a complex system, there will be situations you didn't expect.
I'd rather that in such a situation, it does not crash completely.
The problem occurs when my software is calling invokeLater()
which I get to by calling in this order:
JSVGComponent.getUpdateManager()
UpdateManager.getUpdateRunnableQueue()
RunnableQueue.invokeLater()
... and at the same time a panel resize causes
JGVTComponent.scheduleGVTRendering() to get called...
I will look into this logic, and set up this call so that the update
queued up, and only the latest one happens (after a delay of, say, 1/4
second). The bug may have been caused by multiple calls to
scheduleGVTRendering() in fast succession when dragging the window
corner.
> >I've come across this type of problem before in other applications: its
> >due to Sun's HashMap not being thread safe. I looked at the problem and
> >decided that it would not take much effort to write a new HashMap class
> >which was just as fast, and also thread safe.
> >
> >My new HashMap is fast, and its only synchronised where it absolutely
> >needs to be. It is completely thread safe - no concurrent modification
> >problems, and no blocking thread contentions.
> >
> >I've modifying my copy of Batic sources so that it uses my HashMap
> >rather than any other HashMap or HashTable classes (Suns's or Batik's).
> >With the new HashMap class, the contentions go away, and I think this
> >results in a MUCH more stable SVG renderer.
> >
> >
> Did you replace _all_ instances of HashMap/HashTable? No offence,
> doesn't that
> strike you as a band-aid approach? For this to be the 'correct' answer
> one would
> have to believe that HashMaps are the only concurrency issue in all of
> Batik. I would
> really be much more interested in finding out what is causing the
> concurrent accesses
> than attempting to make everything multi-thread safe, which is the road
> you are headed
> down.
>
> >Can I put these changes in to Batik's source code? Who should I talk to?
> >
> Vincent usually handles large contributions, but I'm not sure we are
> there yet.
I'm glad to talk this through some more.
>
>
> ---------------------------------------------------------------------
> 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]
