> I'm not a C++ expert but I assume that the C++11 atomic semantics are defined with respect to the atomic operations on the atomic objects.
C++ defines memory ordering among both atomic and ordinary
load/stores/read-modify-writes. Upon each operation on atomics the
programmer selects whether ordinary loads or stores can be reordered
with this operation. Operations on atomics are ordered among
themselves regardless of requested memory ordering.
(And there's a atomic_thread_fence if you want to order loads/stores
without any synchronizing operation.)
Have a look here: https://en.cppreference.com/w/cpp/atomic/memory_order
> But still - for C++ atomics this relies on compiler-defined behavior.
Is required from a C++11-compliant compiler to respect requested
memory ordering, both when optimising code and producing machine code.
> AFAIK The C++ memory model does not define flushing.
I also don't think C++ defines "flushing" – but why would a programmer
care about it? C++ restricts what one thread can see when another
thread issues several operations, abstracting from where the data
sits.
C++ standards so far are not compatible with pmem – I believe that the
main problem is that reading a data item without writing it beforehand
is considered "undefined behaviour", and that happens when you read
from pmem.
To view this discussion on the web visit https://groups.google.com/d/msgid/pmem/ba741667-b5c1-45b1-8c1b-96b4885c7d2an%40googlegroups.com.
Looks like the CAS is independent with the previous instructions, check the CAS description, it just keep the CAS operation as atomic instead assure the previous store finished. I think fense() is still needed.
To view this discussion on the web visit https://groups.google.com/d/msgid/pmem/CAJWudzBBbsd_i88kfD5%3DZB8rRP%2B__wEpJhNxkFApMNM_MP1PPg%40mail.gmail.com.