Map m = Collections.synchronizedMap(new HashMap());
Do you feel that yours is more intuitive? Faster? Cleaner? Simpler? Does the above simply not work?
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... BrianOn 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..
