In 2004,  Andrei and I coauthored an article about why it was not possible to write a safe implementation of double-checked locking in standard C++.  Between compiler optimizers performing code motion and hardware MMUs reordering loads and stores, there was no way to prevent transformations that could cause safe-looking source code to yield incorrect runtime behavior.

But that was for C++98, which, because it had no concept of threads, had no memory model, so it offered no guarantees regarding the visibility of reads and writes across threads.  C++0x does have a memory model, and the changes to the language and library are significant.  Sequence points no longer exist, having been replaced with the “sequenced before” and “happens before” relationships.  Atomic types offer memory visibility guarantees not offered by non-atomic types, and compilers must generate code that respects these guarantees.  These guarantees make it possible to prevent the kind of unwanted code motion and memory access reorderings that bedevil double-checked locking in C++98, although they’re not enough:  the core language must also constrain the relationship between memory allocation and object construction in a new expression.  C++0x provides such constraints.

Like most languages that recognize the existence of multiple threads, C++0x offers programmers a mechanism for ensuring sequential consistency in concurrent code.  In contrast to other languages (and in recognition of C++’s role as a systems programming language), C++0x offers fine-grained control over the constraints imposed on compilers and hardware when optimizing, making it possible to implement consistency models weaker — and hence potentially faster — than sequential consistency.

This talk will address  the topics mentioned above:  double-checked locking (briefly — I’ll assume you’ve read Andrei’s and my above-mentioned article in advance), compiler optimizations, memory access reorderings, “sequenced before” and “happens before” relations, atomic types, memory consistency models, and how they relate to both correctness and performance.  Also, because it’s pretty much obligatory in this kind of talk, I’ll address the potentially confusing relationship between atomic and volatile types.

I welcome your feedback on this talk topic.

Scott