Ongoing Optimization: A Data Race with CppMem
But we can improve and further improve the acquire-release semantics of the last post. Why should x be atomic? There is no reason. That was my first but incorrect assumption. See why?
This author has not written his bio yet.
But we are proud to say that Rainer Grimm contributed 698 entries already.
But we can improve and further improve the acquire-release semantics of the last post. Why should x be atomic? There is no reason. That was my first but incorrect assumption. See why?
With the acquire-release semantics, we break the sequential consistency. In the acquire-release semantics, synchronization occurs between atomic operations on the same atomic and not between threads.
With atomic data types, you can tailor your program to your needs and optimize it. But now we are in the domain of multithreading experts.
The easiest way to solve the undefined behaviour in the post Ongoing Optimization: Unsynchronized access is, to use a lock.
Something completely different. I’m looking for English proofreaders for my new book.
I described my challenge in the last post. Let’s ‘s 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 relatively easy. A small program should undergo ongoing optimization.
CppMem is an interactive tool for exploring the behavior of small code snippets of the C++ memory model. No, it should have to be in the toolbox of each programmer who deals seriously with the memory model.
The relaxed semantics is the end of the scale. The relaxed semantic is the weakest of all memory models and guarantees that the operations on atomic variables are atomic.
Acquire and release fences guarantee similar synchronization and ordering constraints as atomics with acquire-release semantics. Similar because the differences are in the details.