Yes, all modifications to a particular atomic object occur in some particular total order, called the modification order. So relaxed read-modify-write operations are still totally ordered with respect to the modified object. Unfortunately that part had to be omitted to keep the article short enough, but you can find more information in the referenced “Memory Models for C/C++ Programmers” white paper : https://arxiv.org/abs/1803.04432
It is important to note that the memory order only orders _surrounding_ operations. So in your example with the fetch_add, it is indeed guaranteed that no two threads see the same value.

So this means that if multiple threads execute counter.fetch_add(1, std::memory_order_relaxed) they will still execute it in some order one after the other? They cannot execute it in parrarel and see the same value at the same time?

The “as-if” rule is specific to C++, but the requirement for a clearly defined memory model is shared by all languages that allow mutation of shared state – so yes, this includes Rust and Go. When multiple threads access mutable shared state, you simply need a memory model to define how the program behaves, e.g.., if/when writes become visible. Java was the language to receive a fully defined memory model. Nowadays Go also has a defined memory model (https://golang.org/ref/mem), but for Rust the memory model is not yet fully defined (https://doc.rust-lang.org/reference/memory-model.html).

Functional languages like Erlang or Haskell use a different concurrency model and do not allow mutation of shared state, so there you don’t have these kind of problems.

I came to this article because I wanted to know if ArangoDB can run on graviton instances. I personally don’t know much about memory management in C++ and was mind blown to find out how compiler optimization can reorder the instructions. Thank you for the detailed write up, especially that it explains perfectly why concurrency is difficult on ARM and why would X86 remains preferred over ARM in spite of the increasing adoption of ARM, at least for the time being.

You may not have the answer to this, but I don’t know who else to ask. Is the “as-if” compiler optimization unique to C++ ? theoretically speaking would languages like Rust or Go that pride themselves on safe concurrency be able to help with ARM architecture adoption or would they have the same issue ?