----------------- > So in some implementations of any class ... 'read' methods may or may not be > thread safe depending on the implementation.
Even if the underlying data is fixed and doesn't change? ---------------- "it depends" on the implementation. One can write thread-safe code and one can write thread-unsafe code. Writing thread-safe code is much more complex then it seems on the surface and usually adds performance overhead in single-threaded use cases. In the case of DOM (from what I'm reading) the underlying *model* is fixed but the actual underlying *implementation* of the model is not. When you call some methods (for presumably "read") the implementation changes things, presumably for optimization purposes. This is not as crazy as it sounds. Imagine a List class with a "length()" method. The first time the length() method is called it walks the list and then stores the size internally to a variable so that future calls to length() return this size. The data model hasn't changed, but the actual implementation state data has. This could possibly be not thread-safe. XML trees are much more complex than this. This is why multithreaded programming is much more complex than it looks on the surface. In some ways it's a disservice to programmers to make thread creation so easy in java because it leaves one the impression that writing thread-safe software is easy (because the 'hard part' is creating threads right ? ) Nope. The really hard part is knowing positively what every single statement is doing under-the-hood in every function call, class and library. And then realizing that is nearly impossible to do, using architectures that avoid accessing common resources across multiple threads or using synchronization on them. Even synchronization is not a panacea. It may protect a single block, but it doesn't solve everything. ---------------------------------------- David A. Lee d...@calldei.com http://www.xmlsh.org -- Andrew Welch http://andrewjwelch.com --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
