I remember when multi-threaded was only on a single core

I spent the last couple of days watching Herb Sutter’s excellent presentations on the C++ 11 memory model and the atomic type that has been added to the language. C++ is an interesting language as it attempts to get you close to the hardware while at the same time trying to make things abstract enough that it is possible to write code that targets multiple platforms.

For C++ 11, the authors of the C++ specification have followed Java’s lead, and defined the language to be sequentially consistent for data race free programs – sequential consistency meaning that the result of running code always looks like an interleaving of the lines of the code as you’d see it running on a single thread (though this is perhaps a little ill-defined when you realise that a single line of source code may need to be mapped into a more base version of the language before compilation for the processor). Herb Sutter’s talk is a great introduction to modern hardware, and the optimisations that the compiler might want to do to the code, and covers how these might interact to make the program behave in a way that is non-deterministic.

Why are memory models interesting? Most programs are going to be written using locks, which guarantee the view that multiple threads have of the lock controlled shared memory. However, there are always occasions where it feels like too much overhead to take a lock, and you just want to define a field in an object which multiple threads can use to share some information. Volatile, in C#, is the way that you can get some of the behaviour of C++ atomics, though the semantics of volatile in C# aren’t always as tight as you may like (see the discussion of volatile write reordering here). C++ and its relaxed atomics make it possible to see some of the trade offs, and the common patterns that can be implemented with weaker forms of memory model guarantees. To be honest though, the main reason to understand a memory model is to be able to point out to people the problems in their implementation of lock free lazy initialization and make one aware of some of the danger areas when compiling ones C# application for ARM architectures.

To me the whole area is just interesting as it demonstrates the trade off between the simplifications to allow fast hardware implementation against the difficulty this gives compiler writers. It will be interesting to see if hardware models continue to evolve towards sequential consistency as Herb Sutter suggests in his talk, making all of this memory model work fairly redundant in the future.