acquire-release semantic

Blocking, non-blocking, lock-free and wait-free. Each of these terms describes a key characteristic of an algorithm when executed in a concurrent environment. So, reasoning about the runtime behaviour of your program often means to put your algorithm in the right bucket. Therefore, this post is about buckets.

There are a lot of issues with the singleton pattern. I'm totally aware of that. But the singleton pattern is an ideal use case for a variable, which has only to be initialized in a thread safe way. From that point on you can use it without synchronization. So in this post I discuss different ways to initialize a singleton in a multithreading environment. You get the performance numbers and can reason about your uses cases for the thread safe initialization of a variable.

But we can do better and further improve the acquire-release semantic of the last post. Why should x be an atomic? There is no reason. That was my first, but incorrect assumption. See why?

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 and release fences guarantees similar synchronisation and ordering constraints as atomics with acquire-release semantic. Similar, because the differences are in the details.

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

A release operation synchronizes-with an acquire operation on the same atomic variable. So we can easily synchronise threads, if ... . Today's post is about the if.