Ongoing Optimization: Acquire-Release Semantic with CppMem


With the acquire-releae semantic, we break the sequential consistency. In the acquire-release semantic the synchronization takes place between atomic operations on the same atomic and not between threads.


Acquire-release semantic

The acquire-release semantic is more lightweight and therefore faster than the sequential consistency, because the synchronization only takes place between atomic operations. But although the intellectual challenge increases.

// ongoingOptimizationAcquireRelease.cpp

#include <atomic>
#include <iostream>
#include <thread>

std::atomic<int> x{0};
std::atomic<int> y{0};

void writing(){,std::memory_order_relaxed);,std::memory_order_release);

void reading(){  
  std::cout << y.load(std::memory_order_acquire) << " ";  
  std::cout << x.load(std::memory_order_relaxed) << std::endl;

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


On the first glance you will notice, that all operations are atomic. So the program is well defined. But the second glance shows more. The atomic operations on y are attached with the flag std::memory_order_release (line 12) and std::memory_order_acquire (line 16). In opposite to that, the atomic operations on x are annotated with std::memory_order_relaxed. So there is no synchronization and ordering constraints for x. The key for the possible values for x and y can only be answered by y.

It holds:

  1.,std::memory_order_release) synchronizes-with y.load(std::memory_order_acquire)
  2.,std::memory_order_relaxed is visible before,std::memory_order_release)
  3. y.load(std::memory_order_acquire) is visible before x.load(std::memory_order_relaxed)

I will elaborate a little bit more on these three statements. The key idea is, that the store of y in line 10 synchronizes with the load of y in line 16. The reason is, that the operations takes place on the same atomic and they follow the acquire-release semantic. So y uses std::memory_order_release in line 12 and std::memory_order_acquire in line 16. But the pairwise operations on y have another very interesting property. They establish a kind of barrier relative to y. So,std::memory_order_relaxed) can not be executed after, so x.load() can not be executed before y.load().  

The reasoning was in the case of the acquire-release semantic a more sophisticated than in the case of the sequential consistency. But the possible values for x and y are the same. Only the combination y == 11 and x == 0 is no possible.

There are three different interleavings of the threads possible, which produces in the three different combinations of the values x and y.

  1. thread1 will be executed before thread2.
  2. thread2 will be executed before thread1.
  3. thread1 executes, before thread2 will be exectued.


At the end the table.



At first, the program once more with CppMem.

int main(){
  atomic_int x= 0; 
  atomic_int y= 0;
  {{{ {,memory_order_relaxed);,memory_order_release);
  ||| {


We already know, all results except of (y=11, x=0) are possible.

Possible executions

Have a look at the three graphs, with the consistent execution. The graphs show, that there is an acquire-release semantic between the store-release of y and the load-acquire from y. It makes no difference, if the reading of y (rf) takes places in the main thread or in a separate thread. The graphs show the synchronizes-with relation with a sw arrow.


Execution for (y=0, x= 0)


Execution for (y= 0, x= 2000)


Execution for (y=11, x= 2000)


What's next?

But we can do better. Why should x be an atomic? There is no reason. That was my first, but incorrect assumption. Why? You will read in the next post.






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, 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, Daniel Hufschläger, Alessandro Pezzato, Evangelos Denaxas, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Ralf Holly, Juan Dent, George Liao, Daniel Ceperley, and Jon T Hess.


Thanks in particular to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, Ralf Abramowitsch, John Nebel, and Mipko.



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small


My special thanks to PVS-Studio PVC Logo


Mentoring Program in English

Do you want to stay informed about my mentoring programs? Write to This email address is being protected from spambots. You need JavaScript enabled to view it..


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 #1 Jeffery 2017-09-08 13:47
bookmarked!!, I love your web site!

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 2797

Yesterday 6750

Week 17134

Month 237970

All 9711602

Currently are 222 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments