This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/4] Add atomic operations similar to those provided by C11.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Wed, 29 Oct 2014 23:06:24 +0000
- Subject: Re: [PATCH 2/4] Add atomic operations similar to those provided by C11.
- Authentication-results: sourceware.org; auth=none
- References: <1414617613 dot 10085 dot 23 dot camel at triegel dot csb> <1414619416 dot 10085 dot 46 dot camel at triegel dot csb> <Pine dot LNX dot 4 dot 64 dot 1410292156440 dot 15119 at digraph dot polyomino dot org dot uk> <1414622734 dot 10085 dot 76 dot camel at triegel dot csb>
On Wed, 29 Oct 2014, Torvald Riegel wrote:
> First, do you agree that we need to make the compiler aware of
> concurrency? For example, it would be bad if the compiler assumes that
> it can safely reload from an atomic variable just because it was able to
> prove that the loading thread didn't change it in the meantime.
I believe that the code already makes it explicit where such reloading
would be problematic, either (a) using asm with appropriate clobbers so
the compiler doesn't know the value is unchanged or (b) using volatile.
In principle atomics could avoid optimization limitations from use of
volatile (and allow more code motion than might be allowed by the asms),
but it's not clear if they do improve on volatile at present.
> If we assume that, we can either (1) use __atomic* and check all the
> generated code, or (2) use inline asm, or (3) use volatile inline asm.
> Any other options? Plain loads will not reliably make the compiler
> aware that it has to take concurrent accesses into account.
As noted, I think appropriate asms or volatile are already in place where
this is an issue for a plain load.
> That might also mean that atomic_store_relaxed should actually use
> inline asm (see the comment in the patch). Thoughts?
Well, I don't see a need to supplement __atomic_* with inline asm. In the
case of not using __atomic_*, if you find you are replacing places with
such asms (and there aren't that many) then the replacement may need such
an asm, but if replacing other places it may be less obvious if an asm is
needed (or if it will make any code generation difference; if not, it
should be safe).
--
Joseph S. Myers
joseph@codesourcery.com