Consensus: data-race freedom as default for glibc code

[Florian Weimer]

On 11/21/2014 11:27 PM, Torvald Riegel wrote:
>> I agree with the idea, but I don't particularly like the term “data race
>> freedom”.
>
> That's what the language standard and the language committee use, so
> that's why I picked that term.

I know, it's just that it's sometimes used differently in the sense that 
you don't know precisely what value you will read, but it's from a 
specific set, and the algorithm can cope with any chosen value.

> What would you propose to improve the wording?  Stress that this
> statement is about glibc's implementation only, not making a statement
> about how glibc is used?

Perhaps something like this?

 >   * Parallel algorithms implemented in glibc itself will be free from
 >     data races (as defined by C11 and its memory model) by 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."


-- 
Florian Weimer / Red Hat Product Security