RE: Xerces-C thread-safe rules

["Houle, Dennis W" <De...@West.Boeing.com>]

Andy -
Thanks for the multithreading clarifications.

How are your multithreading efficiency studies progressing?

If I guarantee (via external synchronization) that only a single thread will
ever be active in a parser instance, can I forgo implementation of the
PlatformUtils mutexes and atomic operations?

The motivation for this is that in my application, the multiple users of the
parser will each make entire sequences of parser accesses atomic (via
lockParser() and unlockParser() operations in a parser wrapper class).  So
we want to avoid the extra overhead of the parser internally taking and
releasing a mutex on each parser access within the atomic sequences.

Thanks for your insights.

- Dennis


-----Original Message-----
From: Andy Heninger [mailto:andyh@jtcsv.com]
Sent: Thursday, February 22, 2001 8:12 PM
To: xerces-c-dev@xml.apache.org
Subject: Re: Xerces-C thread-safe rules


From: "Houle, Dennis W" <De...@West.Boeing.com>

> I'm porting Xerces to a single process/multi-thread O/S (VxWorks) and
need
> to design the port so that Xerces will be thread-safe.

I don't think that there's much to design.  Just provide the mutex and
atomic operations in PlatformUtils and all else should be fine.

>
> The Xerces-C FAQ provides some rules to ensure safe use on a
multi-threading
> O/S.
>
> Are these rules still current and complete?

Yes.

> In particular, "... any given document instance can only be accessed by
one
> thread at a time." especially in light of the use of mutexes in the
> XMLPlatformUtils class.  What type of thread safety is being provided by
> these mutexes?

The mutexes are used to synchronize things that are global to all
documents, like the string handle heap.

The DOM design we have now has efficiency problems with multithreaded
applications, esp. on SMP machines.  The problems come mainly from heavy
heap usage.  I've been looking into alternative approaches, and have some
interesting preliminary results.  I'll get more info posted soon, probably
early next week.  One of the things that I would like to see is concurrent
read access to a DOM document without requiring synchronization.  This
means truly concurrent, not just burying the synchronization in the DOM
implementation, as that would kill performance on SMP machines.  (See mail
thread on DOM performance, starting 1/31)

But for purposes of your port, I don't think that you need to worry much
about where the DOM might be headed.  Just port the platform utils and
everything should work and stay working.  Separate from the porting
questions, though, thoughts on multithreaded use of the DOM are always
good to hear.

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




---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org