On Wed, Oct 5, 2011 at 5:49 AM, Andrew MacLeod <amacl...@redhat.com> wrote: > On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote: >> I see two ways out: >> 1) Say that accessing a non-volatile atomic through a volatile >> reference or pointer causes undefined behavior. The standard doesn't >> say that, and the casts are implicit, so this is icky. >> 2) Say that volatile atomic accesses may be implemented with more than >> one instruction-level access. >> >> (2) is something like how volatile reads of 128-bit structs involve >> multiple mov instructions that execute in an arbitrary order. It's >> also unlikely to cause problems in existing programs because nobody's >> using volatile atomics yet, and they'll only start using them in ways >> that work with what compilers implement. > > To clarify, you are suggesting that we say atomic accesses to volatile > objects may involve more than a single load? > > Can we also state that a 'harmless' store may also happen? (ie, a 0 to an > existing 0, or some other arbitrary value) Otherwise I don't know how to > get a 128 bit atomic load on x86-64 :-P which then means no inlined > lock-free atomics on 16 byte values. > Its unpleasant, but... other suggestions?
Yes, that's what I'm suggesting. The rule for 'volatile' from the language is just that "Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine." If the instruction-level implementation for a 16-byte atomic load is cmpxchg16b, then that's just how the abstract machine is implemented, and the rule says you have to do that consistently for volatile objects rather than sometimes optimizing it away. That's my argument anyway. If there's another standard you're following beyond "kernel people tend to ask for it," the situation may be trickier. Jeffrey P.S. On x86, cmpxchg's description says, "To simplify the interface to the processor’s bus, the destination operand receives a write cycle without regard to the result of the comparison. The destination operand is written back if the comparison fails; otherwise, the source operand is written into the destination. (The processor never produces a locked read without also producing a locked write.)", so 128-bit atomic loads will always write the original value back.
