On 2/27/12, Andrew MacLeod <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
