The functions for atomic operations described above are either +implemented via compiler intrinsics (if the underlying host is +capable) or by library fallbacks.
Compiler intrinsics (builtins) are always preferred. However, as
+the compiler builtins for atomics are not universally implemented,
+using them directly is problematic, and can result in undefined
+function calls. (An example of an undefined symbol from the use
+of __sync_fetch_and_add on an unsupported host is a
+missing reference to __sync_fetch_and_add_4.)
+
In addition, on some hosts the compiler intrinsics are enabled
+conditionally, via the -march command line flag. This makes
+usage vary depending on the target hardware and the flags used during
+compile.
+
+If builtins are possible for bool-sized integral types,
+_GLIBCXX_ATOMIC_BUILTINS_1 will be defined.
+If builtins are possible for int-sized integral types,
+_GLIBCXX_ATOMIC_BUILTINS_4 will be defined.
+
For the following hosts, intrinsics are enabled by default. +
alpha
ia64
powerpc
s390
For others, some form of -march may work. On
+non-ancient x86 hardware, -march=native usually does the
+trick.
For hosts without compiler intrinsics, but with capable +hardware, hand-crafted assembly is selected. This is the case for the following hosts: +
cris
hppa
i386
i486
m48k
mips
sparc
And for the rest, a simulated atomic lock via pthreads. +
Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation. +
More details on the library fallbacks from the porting section. +
A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract +the thread interface for GCC. This layer is called "gthread," and is +comprised of one header file that wraps the host's default thread layer with +a POSIX-like interface. +
The file <gthr-default.h> points to the deduced wrapper for +the current host. In libstdc++ implementation files, +<bits/gthr.h> is used to select the proper gthreads file. +
Within libstdc++ sources, all calls to underlying thread functionality +use this layer. More detail as to the specific interface can be found in the source documentation. +
By design, the gthread layer is interoperable with the types,
+functions, and usage found in the usual <pthread.h> file,
+including pthread_t, pthread_once_t, pthread_create,
+etc.
+