On Sep 9, 2011, at 04:17, Jakub Jelinek wrote: > I'd say they should be optimization barriers too (and at the tree level > they I think work that way, being represented as function calls), so if > they don't act as memory barriers in RTL, the *.md patterns should be > fixed. The only exception should be IMHO the __SYNC_MEM_RELAXED > variants - if the CPU can reorder memory accesses across them at will, > why shouldn't the compiler be able to do the same as well?
They are different concepts. If a program runs on a single processor, all memory operations will appear to be sequentially consistent, even if the CPU reorders them at the hardware level. However, compiler optimizations can still cause multiple threads to see the accesses as not sequentially consistent. For example, for atomic objects accessed only from a single processor (but possibly multiple threads), you'd not want the compiler to reorder memory accesses to global variables across the atomic operations, but you wouldn't have to emit the expensive fences. For the C++0x atomic types there are: void A::store(C desired, memory_order order = memory_order_seq_cst) volatile; void A::store(C desired, memory_order order = memory_order_seq_cst); where the first variant (with order = memory_order_relaxed) would allow fences to be omitted, while still preventing the compiler from reordering memory accesses, IIUC. To be honest, I can't quite see the use of completely unordered atomic operations, where we not even prohibit compiler optimizations. It would seem if we guarantee that a variable will not be accessed concurrently from any other thread, we wouldn't need the operation to be atomic in the first place. That said, it's quite likely I'm missing something here. For Ada, all atomic accesses are always memory_order_seq_cst, and we just care about being able to optimize accesses if we know they'll be done from the same processor. For the C++11 model, thinking about the semantics of any memory orders other than memory_order_seq_cst and their interaction with operations with different ordering semantics makes my head hurt. Regards, -Geert
