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 behaviour 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 for the summation of 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 semantic, we have no synchronisations and ordering constraints on atomic operations.

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.

The key idea of a std::atomic_thread_fence is, to establish synchronisation 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 synchronisation and ordering constraints of the operations.