ABSTRACT
Locks are complicated but the complication is unavoidable in real code, even though they do not compose with other locks. Locks are even more impractical for generic programming, because ordering of locks is generally not visible until instantiation. With the introduction of locking (and atomics) in C++11, this now becomes a difficult problem to avoid if you continue to want to use templates.

We know Transactional memory has been one promising way to solve the problem, but it was always thought to be a research toy. No more! Transactional Memory is being willed into reality with full integration into C++, and maybe OpenMP, urged by Hardware and compiler support.

TM Hardware is here, with Intel's Haswell and Broadwell, IBM's BG/Q and Power 8, and previously Sun's Rock. Software TM support has been here for quite some time with Intel's STM, IBM's BG compilers and most recently GCC C++ 4.7.

ISO C++ has just approved a Transactional Memory Technical Specification this year. This proposal has two types of transactions based on V1.1 of the Draft Transactional Memory for C++

that has been worked on since 2008. When published today, it will be

The ISO C++ proposal supports 2 types of transactions as software but can be augmented through hardware:
- an isolated transaction that isolates from non-transactional code (as well as other transactions)
- an ordinary transaction that allows communication with non-transactional code

In this talk which is both a reference and a tutorial, I will present the proposal for Standardization in C++. BSC will be the first institution to see the proposal,after its approval by ISO C++ 2 weeks ago.

In addition, I will also talk about where C++ Standardization is and what is the future plans for parallelism and concurrency.

Conference Information