# C++ Concurrency Model on x86 for Dummies

DevFeed: [C++ Concurrency Model on x86 for Dummies](<https://devfeed.tech/articles/c-concurrency-model-on-x86-for-dummies-25070.md>)

Original publisher: [Read original article](<https://databasearchitects.blogspot.com/2020/10/c-concurrency-model-on-x86-for-dummies.html>)

Author: Viktor Leis (noreply@blogger.com)

Published: 2020-10-30T16:17:00Z

Content type: tutorial

Language: en

Sources: [Database Architects](<https://devfeed.tech/sources/database-architects.md>)

Topics: [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [x86](<https://devfeed.tech/topics/x86.md>), [Compiler](<https://devfeed.tech/topics/compiler.md>), [Data structures](<https://devfeed.tech/topics/data-structures.md>)

Tags: [atomic](<https://devfeed.tech/tags/atomic.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [code](<https://devfeed.tech/tags/code.md>), [compiler](<https://devfeed.tech/tags/compiler.md>), [concurrency](<https://devfeed.tech/tags/concurrency.md>), [data-structures](<https://devfeed.tech/tags/data-structures.md>), [x86](<https://devfeed.tech/tags/x86.md>)

## AI overview

This tutorial explains a practical subset of the C++11 memory model for writing high-performance concurrent code on x86. It emphasizes using std::atomic, choosing memory orders, and avoiding undefined behavior from data races, while noting that the simplified approach may be less efficient on non-x86 platforms such as ARM.

## Source excerpt

Since C++11, multi-threaded C++ code has been governed by a rigorous memory model. The model allows implementing concurrent code such as low-level synchronization primitives or lock-free data structures in a portable fashion. To use the memory model, programmers need to do two things: First, they have to use the std::atomic type for concurrently-accessed memory locations. Second, each atomic operation requires a memory order argument with six options determining the concurrency semantics in terms of which re-orderings are allowed. (Some operations even allow specifying two memory orders!) While there are a number of attempts to describe the model, I always found the full semantics very hard to understand and consequently concurrent code hard to write and reason about. And since we are talking about low-level concurrent code here, making a mistake (like picking the wrong memory order) can lead to disastrous consequences. Luckily, at least on x86, a small subset of the full C++11 memory model is sufficient. In this post, I'll present such a subset that is sufficient to write high-performance concurrent code on x86. This simplification has the advantage that the resulting code is much more likely to be correct, without leaving any performance on the table. (On non-x86 platforms like ARM, code written based on this simplified model will still be correct, but might potentially be slightly slower than necessary.) There are only six things one needs to know to write high-performance concurrent code on x86. 1. Data races are undefined If a data race occurs in C++, the behavior of the program is undefined. Let's unpack that statement. A data race can be defined as two or more threads accessing the same memory location with at least one of the accesses being a write. By default (i.e., without using std::atomic), the compiler may assume that no other thread is concurrently modifying memory. This allows the compiler to optimize the code, for example by reordering or optimizing