[v3] atomics

[Benjamin Kosnik <bkoz at redhat dot com>]

This adds in experimental support for C++0x chapter 29, atomics. It is
based on the sample implementation by Lawrence Crowl in N2427, who
generously allowed libstdc++ use of this code. Thanks Lawrence!

Some implementation notes:

1) C/C++ interface
Although the C++0x draft includes cstdatomic and stdatomic.h, only
cstdatomic is actually specified in any detail. Nevertheless, this
implementation includes a "C" language stdatomic.h file that
interoperates with the C++ cstdatomic file. 

The interface breaks down into:

a) stdatomic.h
for "C", one has atomic_flag and atomic_address, and a
slew of atomic_* integral types. These types are all POD. Then, one
has accessor functions for atomic_flag, and accessor macros (inspired it
seems from tgmath) for atomic operations. 

b) cstdatomic
for C++, one has atomic_flag (and the accessor funtions),
atomic_address, the atomic_integral types, and a generic std::atomic
type. Instead of accessor macros, C++ uses overloaded accessor
functions of the same name.
So, conceivably one could use the atomic_integral types with the
accessors and have it work in either C or C++.

However, to me the std::atomic type seems like the superior design, with
much clear member-function call syntax. I would be surprised if C++
programmers really used anything else...

Placement of the C++ include in the source directory is a bit
haphazard. I put it in include/c_global but really, it should be in
include/c_std. 

Additional support for testing "C" only functionality (including
link tests) from within the libstdc++ testsuite was added. 


2) support for standard layout types.
The C++0x draft for atomics uses default/deleted functions, and standard
layout types. G++ does not support these constructs at the moment, so
we have to work around this, and then update the atomics code when G++
is ready. Support for default/deleted functions is icing and can be
worked around with the usual private default ctor/assignment decls,
but standard layout type support is harder to fake. We cannot actually
have both aggregate initialization and deleted assignment/copy without
support for standard layout types. (As required for atomic_flag,
atomic_address, atomic_[integral_types])

As such, I picked support for simulated deleted assignment/copy in all
cases except for atomic_flag, where aggregate initialization syntax is
currently required by the standard. (FWIW, I think mandating both
atomic_flag as requiring aggregate initialization in C++ and trivial
default copy ctor is over-specification.)

I added a configure-time check for standard layout support, in
GLIBCXX_CHECK_STANDARD_LAYOUT and the associated
_GLIBCXX_USE_STANDARD_LAYOUT define. Some implementation code is
already conditionalized using this.

As part of this, I add appropriate tests for aggregate
init and assign_neg/copy_neg, but did so incompletely. However, there is
enough there that when support for standard layout types goes in, well
get some XPASSES and then I'll go through and make this cleaner. 

Some testing notes:

The testsuite additions are mainly testing
placement (headers, namespace, linkage) and various requirements.
There is very little functionality testing: advice, discussion, and
proposals to add something in this area are wanted.

Because the generic atomic type and the atomic_integral types are
specialized on builtin types, it will be useful to be able to concisely
test required specializations (13, 15 if including new character types).
Because of this, I've implemented
requirements testing for std::atomic using the kinds of testing
techniques long used in the performance testsuite but until now absent
in the usual conformance testing. In particular, typelist-based
checking for templates, which is a way of combining a primary template
(std::atomic) with instantiating types (ie, all the integral types). I
encourage interested people to get used to these ideas,
as it seems like a way to test required specializations without
duplicating code for every single specialization. It is likely
that as support for new character types is added to g++/libstdc++,
these kinds of techniques will be used instead of separate
char/wchar_t/char16_t/char32_t directories and test cases. Consider
this a warning shot across the bow...

;)

There is a documentation part of this (minor) that will be checked in
when I'm done merging 29/30. I will update the various C++0x status
pages at that time.

tested x86/linux
tested x86/linux performance

-benjamin

Attachment: p.20080410-2.bz2
Description: application/bzip