notes on current atomics config and usage

[Benjamin Kosnik <bkoz at redhat dot com>]

The current state of atomic operations support in libstdc++ looks like:
(include/bits/atomicity.h)

__exchange_and_add
__atomic_add
__exchange_and_add_multi
__atomic_add_multi
__exchange_and_add_single
__atomic_add_single
__exchange_and_add_dispatch
__atomic_add_dispatch

These operations are composed of hardware and os-dependent bits, which
are constructed out of:

%cd libstdc++-v3/config/cpu
%find . -type f -name atomicity.h
./sh/atomicity.h
./mips/atomicity.h
./i486/atomicity.h
./sparc/atomicity.h
./generic/atomic_builtins/atomicity.h
./generic/atomicity.h
./i386/atomicity.h
./hppa/atomicity.h
./m68k/atomicity.h
./cris/atomicity.h

There seems to be some issues with mips variants, where we cannot
reliably tell if a particular cpu can hack the libstdc++ atomicity.h
mips asm, but assume that if it can run linux, it can do atomics. Bah.

In addition, 

alpha*
ia64
powerpc*
rs6000
s390*

now support the compiler builtins for atomic operations.

Because the compiler builtins for atomics are not universally
implemented, using them directly is problematic, and can
result in undefined function calls, depending on the target hardware
and the flags used during compile.

This is to be avoided in a general-purpose library such as libstdc++.

Thus, the wrapper functions __exchange* and __atomic* as above.

It is my strong suggestion that priority of support for atomic
operation implementation goes:

1) os level overrides
1) gcc atomic builtins
2) as a limited-time-only transition period thing, existing libstdc++
atomics asm used
3) if none of above, use generic support with heavy locks.

I'd like to move to configure-time testing for atomics, instead of
hard coded lists of platforms that work. In general, this approach
tends to age better... see patch.

Anyway. A real, unsettled meta-question is the use of atomic ops in
inline functions. This seems fine, except for the x86 quandary.

Damn you, i386.

The only solution for i386/i486+ nightmare is to make all atomic calls
non-inline, all calls to atomic operations wrapped in external "C"
functions. Then, during build time, compile in definitions for wrapper
functions to libstdc++. This results in binaries that have no
definitions for atomic operations, only references to the wrapper
functions. Thus, switching between i386 and i486+ becomes just a matter
of swapping libstdc++ packages, instead of rebuilding all the C++
binaries.

The downside of this is that atomic operations cannot be inlined. At
the time this decision was made, convincing evidence of a significant
slowdown in libstdc++ functions using atomics was not shown, and
furthermore the i386/i686 issue was biting every linux distro.

In theory, this really does penalize every other non-x86 linux
platform, however.

-benjamin