Over the past years, we have seen a shift in processors from the previously dominant x86 architecture to the more energy-efficient (and often cheaper) ARM architecture. This trend is true for both consumer hardware, e.g., Apple’s M1 SoC, and also server hardware, e.g. AWS’s Gravitron processor. Given that the ARM architecture has a more relaxed memory model, this might have some subtle impact on C++ programs.

So far, ArangoDB was only built for x86-based CPUs, but due to the rise of ARM processors, we are faced with an ever-increasing number of requests from users to support ARM. Since performance is at the heart of ArangoDB, there are a lot of places where we use atomic operations. In order to ensure that our code behaves correctly on ARM, we have to revisit all those places and make sure that the operations use the correct memory order. But what does that mean?

With the introduction of multi-threaded execution in C++11, the standard also introduced a memory model. For many developers, this memory model is one of the least well-understood parts of the C++ standard and a common source of confusion. While an in-depth explanation of the C++ memory model is beyond this article’s scope, we will cover some basics, as well as take a brief look at two of the most common hardware memory models and how the C++ memory model maps to these hardware models.

#tutorial #c++ #concurrency #x86 #memory model