Xerces-C thread-safe rules

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

Hi,

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.

The Xerces-C FAQ provides some rules to ensure safe use on a multi-threading
O/S.

Are these rules still current and complete?

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?

Thanks!

- Dennis Houle

Re: Xerces-C thread-safe rules

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

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