On 10 Dec 2007, at 20:27, Michael Glavassevich wrote:
Hi Joe,
[EMAIL PROTECTED] wrote on 12/10/2007 01:08:09 PM:
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
I'm saying I don't believe semaphores should be added to the
standard to the standard Xerces DOM. Users can plug in an
appropriate DOM implementation if they need threadsafety at the DOM
level.
Apropos of which: I believe the non-incremental Xerces DOM *is*
already essentially "thread-safe for read", though the demand-
constructed version isn't. If that's all you need, Xerces may
already have solved your problem...?
None of Xerces DOM implementations are thread-safe for read. I can
think of
at least a couple of places in the non-incremental Xerces DOM which
aren't
thread-safe, the getChildNodes() NodeLists being one of them.
Thanks for the confirmation, Michael. That was my impression from
your posts to j-users in March 2006 (included below, and at the
bottom of my previous reply to Joe).
I agree with Joe that we would need to be careful not to
(significantly) impact single-threaded performance when adding the
ability to safely read an unchanging document using multiple threads.
What is your view on my original question?
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)?
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.
