Comment 22 for bug 490371

It seems that the ordered primitives do need fixing, as dmart suggests; for confirmation see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 . I would also think that the ref()/deref() methods should have ordered semantics, since they function like locks (a caller which sees deref() return 0 is entitled to tear down the associated instance).

My personal preference is to use the GCC intrinsics, since they're more likely to get full review, and I'm skeptical of the performance benefits of the "relaxed" primitives in practice (on any system that actually has atomics and doesn't need kernel help). Particularly in the ordered cases, I see no reason whatsoever to embed inline assembly. But I suppose it is not wrong for Qt's "relaxed" primitives to contain equivalent assembly, without the memory barriers -- as long as the compiler won't insert memory operations in between the ldrex/strex pair. (The ARM folks' reading of the ARM ARM is that hardware speculation of memory accesses into the critical region should not break the local monitor.)

Another advantage of using the GCC intrinsics is that they will work for 64-bit operands once this support is in GCC, without embedding yet more complex assembly into Qt. David Gilbert has implemented 64-bit atomics for ARMv7, and I'm helping test; I intend to implement them also for 32-bit x86 (using cmpxchg8b).

Would you entertain a patch that makes the use of inline assembly for the non-ordered primitives optional at compile time? (Via a template specialization, so it still works for double-word operands if the compiler can handle them.)