Several Red Hat engineers attended the JTC1/SC22/WG21 C++ Standards Committee meetings in May 2015 at Lenexa, Kansas, USA. This post focuses on the sessions of SG1, the study group on parallelism and concurrency.
Finishing the Technical Specifications (TSes) was one major point on the agenda of SG1. The Parallelism TS (see this draft) and the Transactional Memory TS (see this draft) have been finalized for publication, and the Concurrency TS and has been made ready for a vote and feedback by the National Bodies. GCC does not yet support those TSes but already has the main functionality required by the Transactional Memory TS through implementing a previous specification of the language constructs for transactions. SG1 is continuing to adding features in those areas, but these will target a version 2 of each of these TSes.
SG1 continues to spend a significant amount of time on standardizing how parallel or concurrent tasks should be executed, including both the semantics of such executions (e.g., forward progress guarantees) and means for programmers to customize when and where computations are performed. There are several proposals in this area, some addressing different aspects and some competing with each other. It's not clear yet which parts of these proposals will end up in a future TS, but SG1 is moving forward on this.
One feature that SG1 wants to see in a version 2 of the Parallelism TS, pending approval by other working groups in the full C++ committee, are the forward progress definitions and requirements that I proposed.
Thread-local storage remains a difficult topic. As it is specified today, it can be costly to support on some implementations (e.g., GPUs with large numbers of hardware threads) -- but it is also used in lots of existing code, for different purposes. SG1 discussed different TLS use cases, and it seems best to tackle them differently (e.g., errno vs. caching scratch space).
Support for SIMD operations and data types using library interfaces was discussed again. There was some progress regarding how to enable ABI stability, but we might end up having to also support types that are not meant to provide a stable ABI so as to exploit hardware differences automatically.
Other topics that SG1 discussed were a proposal about how to enable atomic access to data that is not of an atomic type, and compiler optimizations of atomic accesses.
Read the related article about C++ Standards: Core.
We're always interested to hear what matters to Red Hat Enterprise Linux developers, so if you have comments or questions on any aspects of the upcoming C++ standards - in the concurrency area, or otherwise - please feel free to get in touch with us at rheldevelop AT redhat DOT com or Tweet @RHELdevelop.
Last updated: April 6, 2018