Fences are Memory Barriers


The key idea of a std::atomic_thread_fence is to establish synchronization and ordering constraints between threads without an atomic operation.

std::atomic_thread_fence are called fences or memory barriers. So you immediately get the idea of what a std::atomic_thread_fence is all about.

A std::atomic_thread_fence prevents specific operations can overcome a memory barrier.

Memory barriers

But what does that mean? Specific operations which can not overcome a memory barrier. What kind of operations? From a bird's perspective, we have two operations: Read and write or load and store. So the expression if(resultRead) return result is a load, followed by a store operation.

There are four different ways to combine load and store operations:

  • LoadLoad: A load followed by a load.
  • LoadStore: A load followed by a store.
  • StoreLoad: A store followed by a load.
  • StoreStore: A store followed by a store.

Of course, more complex operations consist of a load and store part (count++). But these operations didn't contradict my general classification.

But what about memory barriers? If you place memory barriers between two operations like LoadLoad, LoadStore, StoreLoad, or StoreStore, you have the guarantee that specific LoadLoad, LoadStore, StoreLoad, or StoreStore operations can not be reordered. The risk of reordering is always given if non-atomics or atomics with relaxed semantics are used. 

Typically, three kinds of memory barriers are used. They are called a full fence, acquire fence and release fence. Only to remind you. Acquire is a load; release is a store operation. So, what happens if I place one of the three memory barriers between the four load and store operations combinations?

  • Full fence: A full fence std::atomic_thread_fence() between two arbitrary operations prevents the reordering of these operations. But that guarantee will not hold for StoreLoad operations. They can be reordered.
  • Acquire fence: An acquire fence std::atomic_thread_fence(std::memory_order_acquire) prevents a read operation before an acquire fence can be reordered with a reading or write operation after the acquire fence.
  • Release fence: A release fence std::memory_thread_fence(std::memory_order_release) prevents a read or write operation before a release fence can be reordered with a write operation after a release fence.

I admit that I invested a lot of energy to get the definitions of an to acquire and release fence and their consequences for lock-free programming. Especially the subtle difference to the acquire-release semantics of atomic operations are not so easy to get. But, before I come to that point, I will illustrate the definitions with graphics.


Rainer D 6 P2 540x540Modernes C++ Mentoring

Be part of my mentoring programs:





Do you want to stay informed about my mentoring programs: Subscribe via E-Mail.

Memory barriers illustrated

Which kind of operations can overcome a memory barrier? Have a look at the following three graphics. If the arrow is crossed with a red barn, the fence prevents this operation.

Full fence


Of course, you can explicitly write instead of std::atomic_thread_fence() std::atomic_thread_fence(std::memory_order_seq_cst). Per default, sequential consistency is used for fences. Is sequential consistency used for a full fence, the std::atomic_thread_fence follows a global order.

Acquire fence


Release fence


But I can depict the three memory barriers even more concisely.

Memory barriers at a glance


What's next?

That was the theory. The practice will follow in the next post. In this post, I compare the first step, an acquire fence with an acquires operation, a release fence with a release operation. In the second step, I port a producer-consumer scenario with acquire release operations to fences. 





Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, 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, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, and Rob North.


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



My special thanks to Embarcadero CBUIDER STUDIO FINAL ICONS 1024 Small


My special thanks to PVS-Studio PVC Logo


My special thanks to Tipi.build tipi.build logo


My special thanks to Take Up Code TakeUpCode 450 60



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.

  • C++ - The Core Language
  • C++ - The Standard Library
  • C++ - Compact
  • C++11 and C++14
  • Concurrency with Modern C++
  • Design Pattern and Architectural Pattern with C++
  • Embedded Programming with Modern C++
  • Generic Programming (Templates) with C++


  • Clean Code with Modern C++
  • C++20

Contact Me

Modernes C++,



+1 #1 Doug Barbieri 2016-07-22 16:18
I can't wait to see the next instalment. I'm still completely in the dark as to what to do with a fence!
+1 #2 Tony 2016-08-06 05:31
One of us is confused.

Typically "StoreLoad" etc is describing a type of fence, not a pair of instructions.

There are two typical classifications of fences, Acquire/Release/etc...

The standard chose to go with the first.

Acquire means "after really is after" ie

x = 17;
if (flag.load(memory_order_acquire))

The use(data) - read or write - can not move above the Acquire.
But the x = 17 can move down.

Release is the opposite:

flag.store(true, memory_order_release);
x = 12;
"before really means before"
use(data) cannot happen after the flag is set, but x = 12 can happen before the flag is set.

Typically Acquire/Release is on read/write instructions, but can be separate barriers.

StoreLoad/LoadStore etc are more Spark-based barriers. They prevent particular movements as their name suggests.
They are always barriers, not tied to read/write instructions.

// x,y,z,w global, r1,r2 local (ie registers)
x = 17;
r1 = y;
r2 = z;
w = 12;

x = 17 Store can't move below r2 = z Load.
Everything else is free to move.

x = 17;
r1 = y;
r2 = z;
w = 12;
u = 3;

x = 17 Store must happen before w = 12 and u = 3 Stores. u can happen before w.
Everything else can move.

Is that at all what you are trying to say?
0 #3 Rainer Grimm 2016-08-15 12:47
Hi, I hope I got you right.

I was not talking about pair of operations like you did it with the acquire release operations. I was only talking about fences with an acquire or release semantic. They establish the orderings in my post (LoadLoad, LoadStore, StoreStore).

Fences are global operations and affect the ordering of other
atomic operations in the thread that executed the fence. (Williams) And I described the orderings in this post, used the terms LoadLoad, LoadStore and StoreStore.
0 #4 Tony 2016-08-17 22:20
Quoting Rainer Grimm:
Hi, I hope I got you right.


described the orderings in this post, used the terms LoadLoad, LoadStore and StoreStore.

Ah, it appears that you are using "LoadLoad" etc slightly differently than what I (and most?) are use to.

I think it makes sense now, although I still prefer "before means before" and "after means after" instead of individual read/write combinations.

0 #5 Rainer Grimm 2016-08-18 05:40
Quoting Tony:

Ah, it appears that you are using "LoadLoad" etc slightly differently than what I (and most?) are use to.


I got my understanding of fences from Jeff Preshing (http://preshing.com/) and Anthony Williams. So my words should be in accordance to theirs.

I like your phrase about (and most). I guess, there are not so many.

0 #6 website 2016-10-27 14:41
I do agree with all the concepts you've presented in your post.
They're really convincing and will certainly work.
Nonetheless, the posts are very quick for newbies. May
you please extend them a little from subsequent time?
Thank you for the post.
0 #7 Cheap Jordans 2016-11-04 08:39
Spot on with this write-up, I truly believe that this website needs a great deal more attention. I�ll probably be returning to see more,
thanks for the info!
0 #8 Yeezy 750 2016-11-29 10:42
Useful info. Lucky me I found your website unintentionally, and I'm shocked why
this coincidence didn't took place earlier! I bookmarked it.

Stay Informed about my Mentoring



English 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

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

Course: Master Software Design Patterns and Architecture in C++

Subscribe to the newsletter (+ pdf bundle)

All tags

Blog archive

Source Code


Today 3884

Yesterday 4344

Week 40762

Month 21008

All 12099217

Currently are 147 guests and no members online

Kubik-Rubik Joomla! Extensions

Latest comments