This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus: data-race freedom as default for glibc code
- From: Torvald Riegel <triegel at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 21 Nov 2014 23:27:04 +0100
- Subject: Re: Consensus: data-race freedom as default for glibc code
- Authentication-results: sourceware.org; auth=none
- References: <1414797659 dot 10085 dot 406 dot camel at triegel dot csb> <1416508239 dot 1771 dot 61 dot camel at triegel dot csb> <546F0733 dot 70304 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?