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

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2014-11-21 at 10:34 +0100, Florian Weimer wrote:
> On 11/20/2014 07:30 PM, Torvald Riegel wrote:
> > "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.
> 
> 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 think what we actually want is that glibc does not rely on 
> (technically) undefined data races

I'm not sure what you mean by that exactly...

> for correct operation when used 
> correctly.  It will still be very easy for programmers to use glibc 
> functions in such a way that they suffer from data races, and the 
> description above could be interpreted as saying that we want to change 
> this.

... but with that I agree.

> To absolutely clear, what I mean is that applicable standards typically 
> do not require any synchronization at all, and we should not start to 
> add synchronization and defensive copies to hide data races (or at least 
> some of their consequences).

Agreed.  We'd have to do something close to that for MT-Safe functions
of course, but even there we have the rules as described in Alex'
MT-Safety annotations.

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?