My contentious view on this is that almost all of the C++ memory model is best ignored. If you write using acquire-fence, release-fence, and everything else re

My contentious view on this is that almost all of the C++ memory model is best ignored. If you write using acquire-fence, release-fence, and everything else relaxed order using gcc style intrinsics then reasoning about the system becomes much easier. As far as I can tell you've also written the optimally performing code. That is, ignore the atomic type entirely and most of the operations. The qualifier above is that it's very difficult to determine what the order annotation on an operation actually means. A fence is certain, it affects everything. An acquire-release fetch_add? Either it only affects ordering of other accesses to the same address or it works as if there were appropriately positioned fences beside it, and I'm not confident there is consensus on which interpretation is correct. If your system considers the order annotation to only refer to that particular address, then there are patterns that can be written with lower overhead than the pure fences strategy. I don't think hardware or compilers work on that basis. Sequentially consistent ordering on parallel systems is also the wrong thing. If you want a magic clock of serialised execution, why are you bothering with atomics.