Consensus: data-race freedom as default for glibc code

[Torvald Riegel <triegel at redhat dot com>]

C11 requires programs to be free of data races (ie, data-race-free,
DRF); otherwise, the program has undefined behavior.  A data race is if
a possible execution contains two memory accesses, at least one of them
is a write, at least one is not an atomic operation, and both are not
ordered by happens-before.  The DRF requirement allows the compiler to
optimize non-atomic operations as if they were sequential code.  (The
compiler must not introduce data races on it's own, though).

Currently, we violate this requirement because we use plain loads/stores
for synchronization, and hope / rely on that the compiler emits those as
actually atomic accesses, does not reload, etc.  While this may work
currently, it's unnecessarily fragile.  Also, it will lead to many false
positives if we should use race detectors that rely on the C11 memory
model.

With the transition to the C11 memory model, we can use loads/stores
with relaxed memory order in place of plain loads/stores.  This has the
following benefits:
1) It tells the compiler to not optimize these operations like
sequential code.
2) It will reduce false positives when using race detectors.
3) It makes it easily visible in the code for which accesses the
programmer needs to consider concurrency, and which are just sequential
code.
4) Loads/stores with relaxed memory order are very efficient (if the HW
supports atomic stores to locations of the respective size and
alignment); they are neither compiler barriers nor require HW barriers.

The transition towards DRF as default will be incremental, and there
might be corner cases where we'll live with benign data races forever
for various reasons.  However, this should be the exception not the
norm.  If we decide to allow a data race in a certain situation because
we reason that it is benign, this must get documented and needs closer
inspection, repeatedly (e.g., to check that the generated code is okay).

(We might also have an incremental transition towards DRF in that we
might have to wait for compilers to optimize relaxed loads/stores
through the __atomic* builtins fully until we can use those builtins.
Such waiting would not help with 1) and 2) above, but 3) would not be
affected.  We will see what we really need when we make the transition.)

Does anyone object to this?