C++ Core Guidelines: The Remaining Rules about Lock-Free Programming
Today, I will finish my story on concurrency and lock-free programming. There are four rules to lock-free programming in the C++ core guidelines left.
This author has not written his bio yet.
But we are proud to say that Rainer Grimm contributed 702 entries already.
Today, I will finish my story on concurrency and lock-free programming. There are four rules to lock-free programming in the C++ core guidelines left.
Today, I will solve the riddle from my last post. Thanks to my readers, the analysis of the ABA problem is quite accurate.
Today, I will finish the rules for 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 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 the executors.
Today, I am writing a scary post about condition variables. You should be aware of these issues of condition variables. The C++ core guideline CP 42 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 must 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 that are bound to your life as creator a new question arises: Will the variables stay valid during […]
If you want to have fun with threads, you should share mutable data between them. To get no data race and, therefore, undefined behavior, you have to think about the synchronization of your threads.
