Re: C++11 atomic library notes

[Andrew MacLeod <amacleod@redhat.com>]

On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
>
> If, as the document proposes, "16 byte volatile will have to call the
> external rotines, but 16 byte non-volatiles would be lock-free.", and
> the external routines use locked accesses for 16-byte volatile
> atomics, then this makes the concurrent accesses to shared_var not
> thread-safe. To be thread-safe, we'd have to call the external
> routines for every 16-byte atomic, not just the volatile ones, and
> those routines would have to use locked accesses uniformly rather than
> distinguishing between volatile and non-volatile accesses. Not good.
>

This would seem to support that an object of a given size must be 
consistent, and that volatility is not a basis to segregate behaviour.
Which is good because thats the result I want but was concerned about :-)
> Even worse, on LL/SC architectures, every lock-free RMW operation
> potentially involves multiple loads, so this interpretation of
> volatility would prohibit lock-free access to all objects.
>
> 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?

Andrew