[cfe-commits] [PATCH] atomic operation builtins, part 1

[Lawrence Crowl]

On 2/27/12, Andrew MacLeod <amacleod at redhat.com> wrote:
> On 02/24/2012 09:24 PM, Girkar, Milind wrote:
> > This does make the size/alignment of the atomic type different
> > from the unqualified type - can somebody highlight the
> > disadvantages due to this difference?
>
> The only thing I can think of is maybe casting.  Casting from a
> smaller object to a larger atomic object could become problematic
> since the atomic may access more memory than the unqualified type
> has allocated.

In general, the atomics will not meet the memory model constraints
if they are accessed through non-atomic lvalues.  Getting anything
sensible out of a particular platform will require a high degree
of understanding of the interaction between language, compiler,
and platform.  I strongly recommend against going there.

The IBM Z-series will be implementing atomics with internal locks.
Any attempt to cross-cast atomic and plain object will likely result
in 'bad things' happening.  Repeat the recommendation here.  :-)

If you need fast access, consider using one of the weaker memory
orders.  Be warned, though, that using them is technically
challenging.

> Casting from atomic to unqualified should be OK as long as the
> padding is at the end of the atomic object.  Does C11 have any
> rules about casting to/from an Atomic?

Yes, C11 section 6.2.5 'Types' paragraph 27.  "The size,
representation, and alignment of an atomic type need not be the
same as those of the corresponding unqualified type."  The wording
is poor, but one can infer intent from the permitted change of
representation.

In C++, atomics are an opaque non-trivially-copyable class type and
the argument types must be trivially-copyable.  You cannot alias
between them under the permitted alias rules.

-- 
Lawrence Crowl