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: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel 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: Mon, 24 Nov 2014 15:29:17 +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> <1416608824 dot 1771 dot 72 dot camel at triegel dot csb>
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