Relaxed Semantics

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 behavior of your program often means putting your algorithm in the right bucket. Therefore, this post is about buckets.

After I've calculated in three different ways the sum of a std::vector I want to draw my conclusions.

Until now, I've used two strategies to summate a std::vector. First, I did the whole math in one thread (Single Threaded: Summation of a vector); second multiple threads shared the same variable for the result (Multithreaded: Summation of a vector). In particular, the second strategy was extremely naive. In this post, I will apply my knowledge of both posts. My goal is that the thread will perform their summation as independently from each other as possible and therefore reduce the synchronization overhead. 

With the relaxed semantics, we have no synchronizations and ordering constraints on atomic operations.

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

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

In this post, our tour through the c++ memory model goes one step deeper. Until now, the posts were only about the atomicity of the atomic data types, but now we deal with the synchronization and ordering constraints of the operations.