"David Lee" <d...@calldei.com> wrote on 06/09/2011 07:35:07 AM:
> ----------------- > > 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. ... and that's exactly what the NodeLists do in Xerces' DOM implementation for length(). Also, each time you call item() it stores the index and last Node returned, so that when you access n+1, it only needs to walk to the next sibling to return the result. Without that optimization the time spent iterating over the NodeList would be O(n^2) instead of linear. > 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 Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
