On Mon, May 30, 2011 at 04:07:09PM -0400, Andrew MacLeod wrote:
> On 05/23/2011 07:05 PM, Joseph S. Myers wrote:
> >On Mon, 23 May 2011, Aldy Hernandez wrote:
> >
> >>This is a patch implementing builtins for an atomic exchange with full,
> >>acquire, and release memory barrier semantics. It is similar to
> >>__sync_lock_test_and_set(), but the target does not have the option of
> >>implementing a reduced functionality of only implementing a store of 1.
> >>Also,
> >>unlike __sync_lock_test_and_set(), we have all three memory barrier
> >>variants.
> >What's the reason you've implemented three variants, rather than six (the
> >C1X/C++0X atomics have six memory order values) or one built-in function
> >taking a memory order parameter? More generally, what is the underlying
> >design here for how built-in functions should cover the whole of the new
> >atomics functionality in C1X and C++0X?
>
> Aldy was just too excited about working on memory model I think :-)
>
> I've been looking at this, and I propose we go this way :
>
> http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen
>
> Please feel free to criticize, comment on, or ask for
> clarification. I usually miss something I meant to get across.
I think the addition of new __sync_* builtins for the different models
is preferrable and would be generally more usable even for other users than
C++ atomics. On some targets any atomic insn will act as a full barrier,
while on others it could generate different insns or code sequences that
way. For OpenMP atomics having a none (in addition to full/acq/rel)
would be useful, I think #pragma omp atomic doesn't impose any ordering
on memory accesses other than the memory being atomically
read/written/changed. Haven't read the C++0x standard in detail why
it has 6 memory order modes instead of just 4, but if really 6 are needed
(even for 4 probably), having new builtins with just one constant extra
argument which says the memory ordering mode would be best.
Jakub
