Re: PATCH: _Atomic_swap implementation for g++-v3/bits/stl_threads.h

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Thu, Oct 04, 2001 at 07:46:35PM -0500, Loren James Rittle wrote:
> In article <20011003215803.A17312@shell7.ba.best.com> you write:
> > ... can't this be done orders of magnitude more efficiently by
> > delegating to the existing libstdc++ atomic operations?  
> ...
> I knew of this option when I wrote the header comment right above the
> new implementation provided by Dimitris' patch (and granted it should
> have been updated when his patch went in): ...
> 
> Are the atomic operations from libstdc++ available and working on
> every platform that supports gthr?  If so, I would have no problem
> changing the implementation to use the atomic operation abstractions
> (probably better to do so before we ever ship it in 3.1).

The atomic operations work everywhere multithreaded operation is
supported at all.  However, the atomic word size supported is not 
necessarily the same as that of the "void*" needed for this 
particular operation.  One can conceive of architectures where 
Dimitris's is the only one that will work, although I believe such 
architectures are rare; maybe rare enough to ignore.

That is, it might be worth retaining Dimitris's implementation as an 
option where configure determines that the word size and pointer size 
aren't the same.  (On some architectures, a char* and a void* are not
the same size; that would argue for changing the Rope code, not the
swap implementation.)  That option could be left unimplemented until
somebody actually ports to such an architecture.
 
> My understanding is that Dimitris has a multi-threaded code base that
> he uses against the rope implementation.  Perhaps, we could convince
> him to investigate the alternate implementation so that the first way
> it ships in gcc 3.1 is closer to optimal.  OTOH, it should be noted
> that this only affects getting a C string reference to a rope string.
> Is that case worth the optimization (especially, if we have to add
> extra configuration paths)?

Are we sure that this is the only place where the operation is useful?
Maybe this is the right way to implement container storage pools when 
running multithreaded, instead of always calling malloc().

Nathan Myers
ncm at cantrip dot org