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: Roland McGrath <roland at hack dot frob dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 31 Oct 2014 19:21:55 -0700 (PDT)
- 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>
That all sounds sensible to me. My immediate reaction was caution in
wanting to see concrete examples of the source changes that would be
entailed and to be prepared to find them cumbersome. But on actual
contemplation, the transition to explicitly annotated RMO loads/stores in
the source seems quite likely to be both relatively straightforward to
understand and relatively noninvasive to the source (even if the changes
are fairly pervasive).
With that in mind, my reaction to your final paragraph is almost the
opposite of my initial caution. That is, I think we should be eager to add
annotations to our code wherever abstractly appropriate irrespective of the
state of compiler optimization intelligence. We can make them no-op macros
rather than invocations of atomic builtins if the compiler is not smart
enough. But there is no reason to force any of our work analyzing and
clarifying DRF issues throughout our source code to have a happens-after
relationship with any particular compiler improvements. Indeed, if there
are static analysis tools available that can be brought to bear, we'd be
well-served by getting our code sufficiently annotated to make them useful
to us well ahead of anything that necessarily affects code generation.
Thanks,
Roland