<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 > > >
