On Mar 7, 2008, at 8:17 AM, Boris Kolpackov wrote:
Hi James,
James Berry <[EMAIL PROTECTED]> writes:
But I did see at least one use of the compareAndSwap routine,
somewhere
in the transcoder support, I believe, though I didn't look into that
usage to see if it's really necessary.
That's a bummer. compareAndSwap is used in TransService.cpp,
WinSock/BinHTTPURLInputSource.cpp, and DOMDocumentTypeImpl.cpp.
The first case can be converted to use fgAtomicMutex as is done
in other places. For WinSock/BinHTTPURLInputSource we can hard-
code Window API calls or use fgAtomicMutex as well (BTW, even
with correct comareAndSwap code in BinHTTPURLInputSource is not
thread-safe on some architectures). The last case should probably
use static initialization. Any thoughts?
I'm not sure I understand the last case well enough to comment at this
point.
The compareAndSwap routine interface is better, as it swaps void*,
which is at least a reasonable type.
We will still have to deal with the insane implementation on POSIX
systems.
There is unfortunately no good (read: fast and standard) way to do
this with posix, from what I've read. Perhaps with autoconfig we could
isolate some of the more common cases or platforms that have direct
support (as we do for Windows/Mac).
I suppose in the end we need to consider the places where this support
is used, and whether the frequency of use is worth the effort and
added complexity in optimizing away the mutex. I will point out,
however, that these implementations have been used since the dawn of
time in Xerces, so it's not like we're introducing a big new
performance penalty: just that there might be an opportunity to make
things better.
By the way, I went ahead and commented out the public interface to
atomicIncrement and atomicDecrement, for now.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
