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:[EMAIL PROTECTED]] Sent: Thursday, February 22, 2001 8:12 PM To: [EMAIL PROTECTED] Subject: Re: Xerces-C thread-safe rules From: "Houle, Dennis W" <[EMAIL PROTECTED]> > 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 [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
