This is the mail archive of the
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 17:23:30 +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> <547340BD dot 4060306 at redhat dot com> <1416842616 dot 1771 dot 138 dot camel at triegel dot csb> <54734DE0 dot 2020606 at redhat dot com> <1416843956 dot 1771 dot 151 dot camel at triegel dot csb>
On 11/24/2014 04:45 PM, Torvald Riegel wrote:
On Mon, 2014-11-24 at 16:25 +0100, Florian Weimer wrote:
On 11/24/2014 04:23 PM, Torvald Riegel wrote:
> * Parallel algorithms implemented in glibc itself will be free from
> data races (as defined by C11 and its memory model) by default.
I changed it to:
* Concurrent code in glibc is free from data races (as defined by C11
and its memory model) by default.
Fine with me as well (although I think technically, this is about
parallelism, not concurrency :-).
And I disagree, that's why I changed it :)
We don't parallelize anything in glibc.
Ugh, we parallelize the execution of threads (unlike the old FSU threads
How would you define both categories?
Concurrency is non-deterministic execution of (sequential) subprograms
in response to external events. Parallelism is the simultaneous,
interleaved execution of subprograms. Or something like thatâbasically,
you can only have high-level race conditions in a concurrent
application, for low-level things (covered by the C11 memory model), you
But I suspect this particular sub-discussion will never have a fruitful
Florian Weimer / Red Hat Product Security