CppMem

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 that provided me precious help in the last years: ThreadSanitizer and CppMem.

With the relaxed semantic, we have no synchronisations and ordering constraints on atomic operations.

But we can do better and further improve the acquire-release semantic of the last post. Why should x be an atomic? There is no reason. That was my first, but incorrect assumption. See why?

With the acquire-releae semantic, we break the sequential consistency. In the acquire-release semantic the synchronization takes place between atomic operations on the same atomic and not between threads.

With atomic data types, you can tailor your program to your needs and therefore optimize it. But now we are in the domain of the multithreading experts.

The easiest way to solve the undefined behaviour in the post Ongoing Optimization: Unsynchronized access is, to use a lock.

I've described my challenge in the last post. Let' start with our process of ongoing optimization. To be sure, I verify my reasoning with CppMem. I once made a big mistake in my presentation at Meeting C++ 2014.

Now it's time to put the theory into practice. The job is quite easy. A small program should undergo an ongoing optimization.

CppMem is an interactive tool for exploring the behaviour of small code snippets of the C++ memory model. It should, no it has to be in the toolbox of each programmer, who deals seriously with the memory model.