Re: [libstdc++] remove __compare_and_swap

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

On Fri, Oct 05, 2001 at 04:30:42PM -0400, Phil Edwards wrote:
> On Fri, Oct 05, 2001 at 12:18:02PM -0700, Nathan Myers wrote:
> > On Fri, Oct 05, 2001 at 02:45:08PM -0400, Phil Edwards wrote:
> > > 
> > > A couple weeks ago I proposed removing __compare_and_swap...
> 
> > Compare-and-swap is an essential primitive to maintain linked data 
> > structures thread-safely without using an enormously more expensive,
> > unportable, and otherwise problematical mutex.
> > 
> > We don't have much in the library yet for support of multithreaded
> > programs, but eliminating primitives that such support would need 
> > seems like the wrong direction to go.
> 
> . o O (Will we ever have that much support?)

I had in mind supporting storage pools for containers (instead of the
enormously slower __USE_MALLOC), and maybe even a more efficient general 
operator new.  

It would be even more valuable for _users_ to be equipped to write 
thread-safe code, without mutexes, portably among gcc targets.  Many 
people use gcc mainly because it is on all the architectures they 
(hope to) use.

Therefore, we should not only retain these primitives, we should
document and expose them in public header files.  (First, though,
we should make sure the client interfaces are exactly right.
Templates would help.)
 
> Note that the recent CRIS port never had __c_a_s in the first place.  
> I, personally, don't see the gain in putting the function back in if
> some parts of config/cpu/ will still not have it.

We can hope that all ports will have the full complement of the primitives 
that they can support.  If, in the more obscure ports, they are stubbed 
out, that provides an obvious opportunity for user participation in the
project.

Note that the i386 target doesn't have __c_a_s either, because the 
necessary instruction doesn't exist on i386.  (That lack is the only 
difference between the i386 and i486 implementations of atomicity.h.)  
That's OK.  On an i386, the less efficient alternative will just have 
to do, or multithreading can be turned off.  (N.B. Given that most 
Linux distros are built for an i386 target, I'd rather see that choice 
made at load time, once library facilities depend on it!)

If the lack of __c_a_s in CRIS justified removing it everywhere else,
wouldn't the lack in i386 have justified that already?

I understand there are similar problems supporting efficient primitives
on SPARC-1 and most HPPA.  Multithreaded libraries on MT-challenged
architectures suffer unavoidable inefficiencies.  The library should
support, as portably as possible, whatever MT efficiencies are possible.
Good MT support does not seem to be getting much less important.

Nathan Myers
ncm at cantrip dot org