This is the mail archive of the
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
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
... 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'
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?