On 10 Dec 2007, at 14:23, [EMAIL PROTECTED] wrote:
Standard response: Making every DOM operation thread-safe would
impose overhead on tasks which don't require it, would be less
efficient than locking at a higher level of your application, and
in fact would be less APPROPRIATE than locking at a higher level of
your application since in general the things you actually want to
guarantee threadsafety for involve multiple DOM operations.
Hence, the DOM Working Group recommended that you implement
threadsafety in the code which uses the DOM rather than in the DOM
itself.
Tying this back to my question, I take Joseph as saying that he
doesn't believe the Xerces DOM should ever be made thread-safe for
read (that is, even when the "multiple DOM operations" are not
modifying the document).
Is that the consensus of this group?
Mark.
On 8 Dec 2007, at 17:32, Mark Goodhand wrote:
All,
I understand that DOM provides no thread safety guarantees, and
that the current Xerces implementation is not thread safe. I've
seen the issue come up on the lists a few times over the past
couple of years. As future hardware improvements are likely to
come in the form of more cores rather than higher clock speeds, and
with XML documents getting larger, I expect user requests for
thread-safety (at least for unchanging documents) will only increase.
As I understand it, it is performance-improving caches that prevent
Xerces DOM from being thread-safe (for read). If true, this is
ironic, considering the massive performance benefits that could
come from parallel processing of documents.
Is the current stance a matter of principle (you don't believe the
Xerces DOM should ever be made thread-safe for read) or a practical
constraint due to limited resources (you'd like the Xerces DOM to
be thread-safe, but other issues/enhancements have higher priority)?
Regards,
Mark.
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: 15 March 2006 19:39:20 GMT
To: [EMAIL PROTECTED]
Subject: Re: xerces DOM concurrent access and defer-node-expansion
Reply-To: [EMAIL PROTECTED]
On Mon, 13 Mar 2006, Michael Glavassevich wrote:
[EMAIL PROTECTED] wrote on 03/07/2006 12:42:55 PM:
If no nodes are being altered by any thread, and
deferred-node-expansion is turned off, is the xerces DOM
concurrently
accessible from multiple threads?
No. For example, you will run into trouble with NodeLists.
Internally they
cache the length and previously accessed position to improve the
performance of calls to getLength() and item(i). Invoking these
methods
from multiple threads (even on different NodeLists) without
synchronizing
your application code will lead to the exceptions [1] observed by
Prashant. You can't count on the other read operations being
thread-safe
either.
Would it work if length and previously accessed position were
stored in
ThreadLocal variables?
Mark.
Begin forwarded message:
From: [EMAIL PROTECTED]
Date: 15 March 2006 22:27:22 GMT
To: [EMAIL PROTECTED]
Subject: Re: xerces DOM concurrent access and defer-node-expansion
Reply-To: [EMAIL PROTECTED]
On Wed, 15 Mar 2006, Joseph Kesselman wrote:
Would it work if length and previously accessed position were
stored in
ThreadLocal variables?
Don't go there. You're starting to talk about imparing performance
for all
users to protect a few who really should be coding higher-level
interlocks
in any case.
It could presumably be implemented as an option.
Mark.
