Relaxed Semantic


The relaxed semantic is the end of the Scala. The relaxed semantic is the weakest of all memory models and guarantees only, that the operations on atomic variables are atomic.

No synchronisation and ordering constraints

That's quite easy. If there are no rules, we can not break them. But that's too easy. The program should have well-defined behaviour. That means in this case: No race condition. To guarantee this, you typically use synchronisation and ordering constraints of stronger memory models to control operations with relaxed semantic. How does this work? A thread can see the effects of another thread in arbitrary order. So, you must only be sure, that there are points in your program, in which all operations on all threads get synchronised.

A typical example of an atomic operation, in which the sequence of operations doesn't matter, is a counter. The key of a counter is not, in which order the different threads increment the counter. The key of the counter is, that all increments are atomic and that all threads are done at the end. Have a look at the example.

// relaxed.cpp

#include <vector>
#include <iostream>
#include <thread>
#include <atomic>
std::atomic<int> cnt = {0};
void f()
    for (int n = 0; n < 1000; ++n) {
        cnt.fetch_add(1, std::memory_order_relaxed);
int main()
    std::vector<std::thread> v;
    for (int n = 0; n < 10; ++n) {
    for (auto& t : v) {
    std::cout << "Final counter value is " << cnt << '\n';


The three most interesting lines are 13, 24, and 26.

In line 13 the atomic number cnt is incremented with relaxed semantic. So, we have the guarantee, that the operation is atomic. The fetch_add operation established an ordering on cnt. The function f (line 10 - 15) is the work package of the threads. Each thread gets its work package in line 21. 

Thread creation is one synchronisation point. The other synchronisation point is the t.join() call in line 24. 

The creator thread synchronises with all its child's in line 24. It waits with the  t.join() call until all its children are done. t.join() is the reason, that the results of the atomic operations are published. To say it more formally: t.join() is a release operation.

In the end, there is a happen-before relation between the increment operation in line 13 and the reading of the counter cnt in line 26.

The result is, that the program returns always 10000. Boring? No, calming!


A typical example for an atomic counter, which uses the relaxed semantic, is the reference counter of std::shared_ptr. That will only hold for the increment operation. The key for incrementing the reference counter is, that the operation is atomic. The order of the increment operations does not matter. That will not hold for the decrementation of the reference counter. These operations need an acquire-release semantic with the destructor.

I want to explicitly say thanks to Anthony Williams, author of the well-known book C++ Concurrency in Action. He gave me very valuable tips for this post. Anthony writes his own blog to concurrency in modern C++:

Business before pleasure

Business before pleasure. That's my simple motto for the next posts. So, I will use the theory about atomics and the memory model in practice.

int x= 0;
int y= 0;

void writing(){
  x= 2000;
  y= 11;

void reading(){ 
  std::cout << "y: " << y << " ";
  std::cout << "x: " << x << std::endl;

int main(){
  std::thread thread1(writing);
  std:.thread thread2(reading);


What's next?

The program looks quite simple. But it has undefined behaviour. Why? I will answer the question in the following post. But that is only the first step. I want to optimise the program. If you want to play with atomics and the memory model, it's always a good idea to have a static code analyser at your disposal. So, in the next post, I will introduce the invaluable precious tool CppMem.




Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, Marko, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, espkk, Louis St-Amour, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Neil Wang, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Tobi Heideman, Daniel Hufschläger, Red Trip, Alexander Schwarz, Tornike Porchxidze, Alessandro Pezzato, Evangelos Denaxas, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Dimitrov Tsvetomir, Leo Goodstadt, Eduardo Velasquez, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, and Michael Young.


Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, and Bhushan Ivatury.



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small



I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.

Bookable (Online)


Standard Seminars (English/German)

Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.


Contact Me

Modernes C++,







0 #11 Rickey 2017-03-27 22:31
I'm still learning ftom you, but I'm making my way to the top as
well. I definitely enjoy reading all that is written on your website.Keep the information coming.

I enjoyed it!

My Newest E-Books

Course: Modern C++ Concurrency in Practice

Course: C++ Standard Library including C++14 & C++17

Course: Embedded Programming with Modern C++

Course: Generic Programming (Templates)

Course: C++ Fundamentals for Professionals

Interactive Course: The All-in-One Guide to C++20

Subscribe to the newsletter (+ pdf bundle)

Blog archive

Source Code


Today 1714

Yesterday 7541

Week 24640

Month 194057

All 7461897

Currently are 158 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments