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.

Today, I'm happy to write about the probably most important rule of the C++ Core Guidelines for concurrency: Whenever feasible use tools to validate your concurrent code. Not all, but a lot of bugs can be detected with tools and each fixed bug is a good bug. Here are two tools which provided me precious help in the last years: ThreadSanitizer and CppMem.

Writing multithreading programs is hard, even harder if the program should be correct. The rules of the C++ Core Guidelines guide you to write correct programs. The rules of this post will deal with data races, sharing of data, tasks, and the infamous keyword volatile.

C++11 is the first C++ standard that deals with concurrency. The basic building block for concurrency is a thread; therefore, most of the rules are explicitly about threads. This changed dramatically with C++17.

Today, I will write about the remaining 10 rules to performance. Ten rules seem to be a lot but only two of them have actual content.

I have prepared the pdf bundle. To get it is quite simple.

In this post, I continue my journey through the rules to performance in the C++ Core Guidelines.  I will mainly write about design for optimisation.