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: "Carlos O'Donell" <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: 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: Thu, 20 Nov 2014 13:55:03 -0500
- 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>
On 11/20/2014 01:30 PM, Torvald Riegel wrote:
> On Sat, 2014-11-01 at 00:20 +0100, Torvald Riegel wrote:
>> C11 requires programs to be free of data races (ie, data-race-free,
>> DRF); otherwise, the program has undefined behavior. 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 DRF requirement allows the compiler to
>> optimize non-atomic operations as if they were sequential code. (The
>> compiler must not introduce data races on it's own, though).
>>
>> Currently, we violate this requirement because we use plain loads/stores
>> for synchronization, and hope / rely on that the compiler emits those as
>> actually atomic accesses, does not reload, etc. While this may work
>> currently, it's unnecessarily fragile. Also, it will lead to many false
>> positives if we should use race detectors that rely on the C11 memory
>> model.
>>
>> With the transition to the C11 memory model, we can use loads/stores
>> with relaxed memory order in place of plain loads/stores. This has the
>> following benefits:
>> 1) It tells the compiler to not optimize these operations like
>> sequential code.
>> 2) It will reduce false positives when using race detectors.
>> 3) It makes it easily visible in the code for which accesses the
>> programmer needs to consider concurrency, and which are just sequential
>> code.
>> 4) Loads/stores with relaxed memory order are very efficient (if the HW
>> supports atomic stores to locations of the respective size and
>> alignment); they are neither compiler barriers nor require HW barriers.
>>
>> The transition towards DRF as default will be incremental, and there
>> might be corner cases where we'll live with benign data races forever
>> for various reasons. However, this should be the exception not the
>> norm. 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).
>>
>> (We might also have an incremental transition towards DRF in that we
>> might have to wait for compilers to optimize relaxed loads/stores
>> through the __atomic* builtins fully until we can use those builtins.
>> Such waiting would not help with 1) and 2) above, but 3) would not be
>> affected. We will see what we really need when we make the transition.)
>>
>> Does anyone object to this?
>
> I've heard agreement from Roland on-list, and no disagreement. Carlos
> hasn't replied on-list, but has made statements on-list that agree with
> having data-race-freedom as default. I would call this consensus,
> despite the lack of active Agreed votes. If you disagree, speak up now.
>
> Carlos suggested to make a note of the outcome in the wiki:
> https://sourceware.org/glibc/wiki/Consensus#Standards_we_use
> ... where I have added the following text:
I agree with all of this :-)
I think it's the only sensible thing to do.
Cheers,
Carlos.