The Interlocked* APIs are a lot cheaper than locking a mutex or even and critical section but are NOT cheap especially on SMP boxes when compared to incrementing an integer. (As was mentioned previously)
Jim > -----Original Message----- > From: Samar Lotia [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 12:21 PM > To: '[EMAIL PROTECTED]' > Subject: RE: Call for Vote: which one to be the Xerces-C++ public > supporte d W3C DOM interface > > > The recommendation is not necessarily to kill the performance > by going for > overkill with a mutex_t object protecting the reference count. Most > platforms provide some form of efficient atomic operations. > Win32 has the > InterlockedXXX range of functions, and platforms such as SPARC provide > support for it in the hardware, so that it is possible to > write efficient > atomic increment, decrement and swap functions that do not > rely on using a > mutex object (see STLport for an example). (can't speak for other > platforms). > > Our (server) application makes HEAVY use of thread safe > reference counted > objects and we can usually max out the CPU on a quad > processor box with > enough load. We have not seen any serious contention problems > when reference > counting is implemented properly. > > Are we paying a penalty for having thread safe reference > counting? Yes! > > Do we want to implement a multi-threaded server application > that shares > objects across threads and do manual memory management for > everything? IMHO, > a resounding No! > > Also, it seems that the proposal being played with involves having the > existing IDOM interface be the default interface with a few > 'smart pointer' > classes which would be doing most of the work for reference counting. > > This seems to suggest that code wishing to refrain from > unnecessary usage of > the ref counting mechanism could use the raw interfaces and > would never hit > the incrCont() and decrCount() methods, hence avoiding the penalty? > > Yes, integer incrememnts/decrements are not free, but then neither are > virtual function calls. So it's a usability vs. performance > question, as > with everything else. Are virtual tables really that terrible > a price to pay > for all the (mostly) error-free behavior they buy you? Similarly, is a > little bit of extra code (i.e. two simple methods), and a > little bit of > memory (4 bytes per Node object), really that bad of a price > to pay for > adding an extremely usable interface to the xerces DOM with > automatic memory > management etc. etc.? > > Finally, > > #ifndef NO_REFCOUNT > NodeImpl::incrCount() > { > #ifdef THRSAFE_REFCOUNT > // ... > #else > ++m_refCount; > #endif > } > #endif > > Samar Lotia > > -----Original Message----- > From: David N Bertoni/Cambridge/IBM > [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 10:40 > To: [EMAIL PROTECTED] > Subject: RE: Call for Vote: which one to be the Xerces-C++ public > supported W3C DOM interface > > > > > [stuff cutted] > > > > > > It looks like we have the following choices: > > > > > > 1. Not support read-only thread safety. > > > 2. Support read-only thread safety at the sacrifice of > leaking memory > and > > > limiting implementation memory models (current IDOM). > > > 3. Support read-only thread safety as you suggest by > performing thread > safe > > > increments and decrements with the possibility that some > performance is > > > lost. > > > > > > If #3 does affect performance, then perhaps read-only > thread safety can > be > > > made an option so that those that don't need it don't pay for it. > > > > The #3 probably has negligable affect on performance as > long as there are > > support in the platform hardware for atomic operations like > test and set. > > Most processors do have this support and it is also often directly > supported > > by the operating system. But making it optional with a > compiler flag is > not > > that hard either. > > My experience has been the opposite of yours. Synchronization is a > performance killer, especially in a multi-threaded, SMP > environment. Don't > kill the new IDOM by saddling it with bad performance > characteristics to > satisfy thread-safe reference counting. > > This is the main reason I'm opposed to the reference-counted > model. It's > intrusive, and those who don't benefit from it are still > forced to pay the > price, which is contrary to the entire philosphy of the C++ > language. I'm > not even interested in the paying the price for integer increments and > decrements, which certainly are not free. > > Dave > > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
