Re: Consensus: data-race freedom as default for glibc code

[Torvald Riegel <triegel at redhat dot com>]

On Sat, 2014-11-01 at 00:20 +0100, Torvald Riegel wrote:
> 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?

I've heard agreement from Roland on-list, and no disagreement.  Carlos
hasn't replied on-list, but has made statements on-list that agree with
having data-race-freedom as default.  I would call this consensus,
despite the lack of active Agreed votes.  If you disagree, speak up now.

Carlos suggested to make a note of the outcome in the wiki:
https://sourceware.org/glibc/wiki/Consensus#Standards_we_use
... where I have added the following text:

"C11 (internally, not exposed via headers): 

      * Data-race freedom, as defined by C11 and it's memory model, is
        the default. 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 transition to data-race freedom will be
        incremental for existing code, but new code should be
        data-race-free. 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). To avoid data races, use
        locks or atomic operations."

If you disagree with this wording, please let me know.