My HashMap is not "synchronized", its threadsafe. i.e. if you have two
threads modifying it at once, it will never throw exception, be
corrupted, or block.
A synchronized class will block, and sometimes a thread contention can
cause part of a program to block "forever".
On Tue, 2003-06-17 at 21:53, Keven Ring wrote:
> Out of curiosity, how significantly different do you feel your
> additional class is from simply changing the constructor for each of
> Batik's HashMaps (or any other implementation of the java.util.Map
> interface) with
>
> Map m = Collections.synchronizedMap(new HashMap());
>
> Do you feel that yours is more intuitive? Faster? Cleaner? Simpler?
> Does the above simply not work?
Perhaps the above may work, but its also possible that it will result in
thread contention. My solution was simpler to patch into the existing
code, its faster (no synchronized blocks).
> Of course, doing the above suggests utilizing the Map interface
> everywhere, rather than assuming a particular implementation (ie,
> HashMap, MyHashMap, etc). Of course, this is what was *intended* by
> Sun.
>
> Brian Modra wrote:
> > 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]
> >
> >
>
>
>
> --
> Keven Ring | They called it Paradise,
> Lead Software Systems Engineer | I don't know why
> The MITRE Corporation | Call someplace Paradise
> (703)883-7026 | and kiss it goodbye..
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
