This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]