<atomic> design

There are currently 3 designs under consideration. They differ in where most of the implmentation work is done. The functionality exposed to the customer should be identical (and conforming) for all three designs.

1. Minimal work for the library
2. Something in between
3. Minimal work for the front end

With any design, the (back end) compiler writer should note:

The decision to implement lock-free operations on any given type (or not) is an ABI-binding decision. One can not change from treating a type as not lock free, to lock free (or vice-versa) without breaking your ABI.

Example:

TU1.cc
-----------
extern atomic<long long> A;
int foo() { return A.compare_exchange_strong(w, x); }

TU2.cc
-----------
extern atomic<long long> A;
void bar() { return A.compare_exchange_strong(y, z); }

If only one of these calls to compare_exchange_strong is implemented with mutex-locked code, then that mutex-locked code will not be executed mutually exclusively of the one implemented in a lock-free manner.