Several Red Hat engineers recently attended the JTC1/SC22/WG21 C++ Standards Committee meetings in Oulu, Finland. This post focuses on the sessions of SG1 (the standards committee sub-group 1 - for concurrency and parallelism) as well as on coroutines-related sessions. Jason already gave an overview of the meeting in his post.
SG1 prioritized proposals and issues affecting the (expected) C++17 standard, followed by proposals targeting the Concurrency TS or a future revision of the Parallelism TS. We also made some progress in the space of coroutines.
The committee decided in the previous meeting to include parallel algorithms in C++17, and two changes to the parallel algorithms facilities were voted into the Committee Draft (CD) of the C++17 standard (these papers will be publicly available soon): P0394R4, which changes exception handling, and P0336R1, which changes the names of the execution policies. We also added a small note (P0371R1) that discourages the use of memory_order_consume, thus notifying users about the state of this feature even though we have no ready replacement currently. Other proposals (e.g., P0053 about a synchronized ostream) were not ready yet and thus will likely be considered for a future version of the standard.
Other noteworthy developments among the 20+ proposals we discussed are the Atomic View (P0019R2) and Floating Point Atomic (P0020R2) proposals, which continue to improve but are not quite finished yet, as is
P0214R1 on Data-Parallel Vector Types & Operations. The std::synchronic proposal (P0162R2) was not discussed at this meeting because conversations that I had with the primary author showed that we might need to tweak the interface to enable high-performance notifications. Executors were discussed as well again this meeting, although this time the discussion was more about how to approach generally with the different proposals rather than about details of specific proposals; SG1 would like to have an executor proposal in the near future, but it is not quite obvious how to get there quickly.
My personal highlight of this meeting was that my papers on forward progress guarantees (P0296R2 and P0299R1; the most recent revisions will be published soon) were voted into the CD. In a nutshell, they clarify when a C++ implementation has to execute code (which differs between typical operating-system threads, parallel tasks, and vector-parallel code) and what it means for a thread to block. I think that these are important changes, and they also allow the standard to clearly specify upcoming features in the parallelism and concurrency space (e.g., executors). From a birds-eye view, forward progress is one aspect of defining threads of execution that are more light-weight than operating-system threads. There is a lot of interest in light-weight threads of execution because they allow programmers to use logically separate, sequential flows of control (i.e., threads of execution) to describe concurrent or parallel execution, without incurring the runtime and space overheads of typical operating system threads.
I also presented a revision of my coroutines / suspendable functions paper (P0073R2) in both SG1 and the language evolution working group. In this revision, I outlined how suspendable functions could be
integrated with schedulers (e.g., how to make schedulers aware of which condition an executing suspendable function blocks on, so that schedulers can execute threads of execution that may satisfy this condition), and showed three examples of how to use suspendable functions: a generator (slighlty revised but similar to the example included in P0073R2) , a replacement for asynchronous parallel algorithms (P0361R0), and wrapping a callback-based external API as a suspendable function. I believe this increased understanding in the committee of how the features I am proposing are supposed to work.
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: March 15, 2023