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]
