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

[Florian Weimer <fweimer at redhat dot com>]

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