This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH 2/4] Add atomic operations similar to those provided by C11.


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


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