Today, I will finish my story to concurrency and lock-free programming in particular. There are four rules to lock-free programming in the C++ core guidelines left.

Today, I solve the riddle from my last post. Thanks to my readers, the analysis of the ABA problem is quite accurate.

Today, I finish the rules to concurrency and continue directly with lock-free programming. Yes, you have read it correctly: lock-free programming.

After the last post to executors, I can now finally write about the unified futures. I write in the post about the long past of the futures and end my detour from the C++ core guidelines.

The update of my book "Concurrency with Modern C++" is available. This version is a total rework of the previous one and includes also new sections such as for executors. In total, the book is 60 pages bigger.

A few weeks ago, one of the authors of the proposal to the futures in C++ Felix Petriconi wrote me an E-Mail. He said my article about std::future Extensions is quite dated. Honestly, he is right. The future of the futures changed mainly because of executors.

Today, I write a scary post about condition variables. You should be aware of this issues of condition variables. The C++ core guideline CP 42 just states: "Don't wait without a condition".

Concurrency provides many ways to shoot yourself in the foot. The rules for today help you to know these dangers and to overcome them.

When you create a new child thread, you have to answer an important question: should you wait for the child or detach yourself from it? If you detach yourself from the newly created child, and your child uses variables which are bound to your lifetime as creator a new question arises: Will the variables stay valid during the lifetime of the child thread?

If you want to have fun with threads, you should share mutable data between them. In order to get no data race and, therefore, undefined behaviour, you have to think about the synchronisation of your threads.