Re: Do DOMStrings really need to be thread-safe?

[Irving Reid <ir...@nevex.com>]

(hey folks, edit out the junk from replies - it makes it much easier 
for people to see what you're trying to say)

>  I just wonder what the reason is that you can't do both?  Can't you have a
>  compile-time option for a thread-safe library (not just DOMString), and a
>  non-thread-safe library?  It would seem to be an easy thing to do.  I use
>  xerces-c for two different apps, one needs the thread safety, and the other
>  doesn't. :-)
>  
>  Jim Reitz

The problem with locking in DOMString is a good example of why you 
don't want a pure "thread-safe" DOM library. If every data structure 
inside a parsed DOM tree was locked and unlocked every time it was 
touched, we'd be spending 70% of our cpu time on locking, instead of 
the 30% we're spending now.

If you look at the standard C++ libraries, such as the STL, none of the 
data structures are locked. The assumption is that the application 
knows best how the data will be used, and therefore it's best to leave 
locking decisions to the application.

 - irving -

Re: Do DOMStrings really need to be thread-safe?

[Andy Heninger <an...@jtcsv.com>]

In general, applications are in a much better position to provide
synchronization than relatively low level libraries.  They know
where it is needed; the libraries don't.

Andy Heninger
IBM XML Technology Group, Cupertino, CA
heninger@us.ibm.com


----- Original Message ----- 
From: "Irving Reid" <ir...@nevex.com>


> The problem with locking in DOMString is a good example of why you 
> don't want a pure "thread-safe" DOM library. If every data structure 
> inside a parsed DOM tree was locked and unlocked every time it was 
> touched, we'd be spending 70% of our cpu time on locking, instead of 
> the 30% we're spending now.
> 

Re: Do DOMStrings really need to be thread-safe?

[Benjamin Geer <be...@btinternet.com>]

On Mon, May 08, 2000 at 07:54:01PM -0400, Irving Reid wrote:
> The problem with locking in DOMString is a good example of why you 
> don't want a pure "thread-safe" DOM library. If every data structure 
> inside a parsed DOM tree was locked and unlocked every time it was 
> touched, we'd be spending 70% of our cpu time on locking, instead of 
> the 30% we're spending now.
> 
> If you look at the standard C++ libraries, such as the STL, none of the 
> data structures are locked. The assumption is that the application 
> knows best how the data will be used, and therefore it's best to leave 
> locking decisions to the application.

There are some things that application locks cannot protect.  For
example, if a string class uses reference counting, and the
reference counting is not thread safe, it is difficult and probably
impossible for the application to work around the problem by using its
own locks.  Reference counting simply must be made thread safe at a
low level.  This is why, in the libstdc++v3 implementation of the
standard C++ libraries, the reference counting code in the standard
string class uses locks.  (They use assembly-language primitives
rather than mutexes, for better performance.)

Benjamin