Thanks, James...a very nice description of the entire topic! "Yea, what he said" :-)
Mike P.S. Perhaps we could convince you to integrate that into the Xerces FAQ section on thread safety? ;-) James Fowler wrote: > > <lecture title="What does thread-safe really mean anyhow?"> > > This is generally a tricky subject - claiming a > component/class/lib/package/whatever is "thread-safe" usually causes a bit > of confusion without further definition of what "thread-safe" means. At > Rogue Wave, we use four different categories of thread-awareness to describe > C++ code. > > A) Single Thread - no synchronization whatsoever, therefore no overhead but > shame on you if (or more probably, when) you use it in an MT app and it core > dumps > > B) Level 1 Thread Safe - lib/class can be safely and sanely used in an MT > app. Safety basically means all access to global data (i.e., static class > vars in C++) is protected with adequate synchronization "behind the scenes". > Sanely is a bit trickier - it means that any "hidden" tricks used at the > class level (like caching, copy-on-write, etc.) do not cause unexpected > behavior when multiple objects share hidden non-static resources, and it > also means that common sequences of operations on a class will work > predictably and consistently in both ST or MT code (normally static > resources which affect behavior may need to be per-thread, instead of > singletons). All this does NOT imply instance level safety, i.e. thread 1 > can work with Foo a while thread 2 works with Foo b with complete safety, > but if both threads want to access Foo a then they must synchronize around a > mutex or some other threading gadget to ensure that only one thread works > with the instance at a time. > > C) Level 2 Thread Safe - all of Level 1 + instance level safety - L2 objects > synchronize themselves. Therefore if class Foo is L2 thread safe, I can use > Foo b in multiple threads at once without worrying about it, because b will > synchronize itself, i.e. all the thread safety is in the methods of Foo > (usually locking a mutex which is a private or protected member of Foo). > This is really nice, easy, and convenient for simple stuff, but it has > drawbacks similar to pessimistic locking on a database. First, performance > takes a major hit, because you are ALWAYS locking, even if only one thread > "sees" the object. Second, you can get backed into some very ugly deadlock > corners if you're not careful (it makes it easy enough for you to get to the > harder problems sooner...). > > D) Thread Hot - the class is L1 or L2 thread safe, and it can create and > manage new threads behind the scenes to do work on your behalf (for example, > an FTP client class which will create a background thread to run the FTP > transfer instead of taking over the calling thread for the entire period). > > </lecture> > > Not trying to offend anyone here, but many people who are just starting into > MT work in C++ kind of assume thread-safety is what we call Level 2 - the > library does _all_ the work. As Dean mentioned, this has some really nasty > performance implications, and only really makes sense for classes that are > designed to have instances shared between lots of threads at once (examples: > an RDBMS connection manager, queues for thread-to-thread communication). > The vast majority of high-performance, scalable C++ apps I've seen rely > predominately on Level 1 thread safety. This means you occasionally have to > do a little more application coding when something actually needs to be > shared - but most need for this can be avoided with good MT-aware > architectural design. It is by far the most common strategy used in the > successful "big" apps I've had direct experience with (mainly financial, > telecomm, & e-commerce frameworks). > > Xerces-C is Level 1 thread safe (or at least mostly so), which is by far the > most appropriate for a parser handling a sequence-dependent syntax (like > XML) if you want to build high performance C++ code. Besides, if you want > simple and slow, you can always use J... (never mind, I didn't say that, I > was not here, where did I put that asbestos jacket... ;) > > James Fowler > Senior Field Architect > Rogue Wave Software > [EMAIL PROTECTED] > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 02, 2000 1:26 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Xerces-C Multithreading > > > > > > > > > > > > I don't think there is any argument at all here. Mike is > > saying that no > > there is not much synchronization in our system because we > > assume that each > > thread has its own parser or that any shared parsers are > > synchronized at > > the application level. Other than static data, of which there > > is a little > > and it must be synchronized, we don't pay any undue overhead for > > synchronization. What Mike (and I) are saying is that, for a > > parser to be > > fully thread safe, it would have to assume the absolute worst > > and would > > have to do huge amounts of synchronization, which everyone > > pays for even if > > they don't need it (and most people don't because they would generally > > naturally move towards the scenario that we adopted anyway.) > > > > So, the argument of your colleague that we are not thread > > safe is someone > > misplaced, and I would imagine that if MSXML has any > > reasonable performance > > at all, that is follows a path not too terribly divergent > > from ours. I.e. I > > doubt it would be thread safe at a fundamental level. And the > > same would > > apply to Java parsers as well as C++ parsers. > > > > ---------------------------------------- > > Dean Roddey > > Software Weenie > > IBM Center for Java Technology - Silicon Valley > > [EMAIL PROTECTED] > > > > > > > > "Wiedmann, Jochen" <[EMAIL PROTECTED]> on > > 03/01/2000 11:13:37 > > PM > > > > Please respond to [EMAIL PROTECTED] > > > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > cc: > > Subject: RE: Xerces-C Multithreading > > > > > > > > > > > As Dean said, it doesn't make sense to make every call > > > thread-safe. This > > > would be a huge overhead, and most people wouldn't need it > > > anyway (locking > > > is always more efficient when done in an application-aware way). > > > > Sorry, but I can't follow you here. Based on the assumption > > of a single parser instance per thread I see no reason for > > locking at all. And if parser instances are shared by threads, > > its surely the task of the application to implement locking. > > > > So why do you see a performance problem? (Of course I follow > > your arguments against MSXML.) > > > > > > Jochen > > > > > >
