Red Hat at the ISO C++ Standards Meeting (March 2016): Parallelism, Concurrency, and Coroutines
Several Red Hat engineers recently attended the JTC1/SC22/WG21 C++ Standards Committee meetings in March 2016 in Jacksonville, Florida, USA. This post focuses on the sessions of SG1 (the standards committee sub-group 1 – for concurrency and parallelism) and on several proposals related to coroutines.
The biggest news from a parallelism and concurrency (P&C) perspective is that the Parallelism Technical Specification v1 was voted into the working draft of the standard.
This means that C++17 will offer support for several parallel algorithms, provided that the standard is approved in the remaining stages of the ISO voting process. If approved, this will make utilizing parallelism easier for many users – e.g., a parallel “for-each” loop, as a simple example.
Several proposals for support of vector execution are also progressing, and I believe that they might be ready before version 2 of the Parallelism Technical Specification is published.
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
Besides parallelism features, SG1 also continued to work on several concurrency features. Two proposals extending the support for atomic operations (namely atomic operations on non-atomic types and a small set of atomic operations on floating point types) seem to be ready to progress to other working groups in the ISO C++ committee.
The std::synchronic proposal is also making good progress, and offers a facility that can be used to wait efficiently for a change to an atomic variable, using a mix of optimized spinning and an OS-level blocking. It has a lot of similarities to the futex mechanism that the Linux kernel has offered for many years. (If you haven’t heard of futexes before, check out the recently updated manpage; while not a tutorial, it now gives a good overview of how this system call works and provides much more details.) Thanks go to several contributors including Linux kernel developers and Red Hatters working on glibc.
My proposals about better specifications of forward progress guarantees also continue to move forward in the standardization process. After being approved by SG1 in past meetings, I spent much time in this meeting in the Core Working Group (CWG), working with them to polish the wording of the base progress definitions. CWG still needs to give its final approval, but I’m hopeful that this will happen in time for this to be included in C++17.
The companion paper that includes wording for additional parallelism-related progress definitions (aiming at being included in Parallelism Technical Specification v2) was approved by the Library Evolution Working Group, and will be the next thing looked at by the Library Working Group.
I am excited about these changes because they both clarify forward progress, which is an essential part of the execution semantics, in the current standard as well as provide a good foundation to specify execution semantics of other kinds of parallel and concurrent execution (e.g., parallel algorithms).
The C++ committee also continued the discussion of the various proposals related to coroutines, notably the so-called “stackful coroutines” and “resumable functions”.
I continue to believe that the use cases for these proposals have more similarities than differences and that these features can be unified, and I presented a more detailed proposal on how that unification can happen and be implemented. This remains an open discussion topic, but I believe than an increasing number of people now think that a unification might be achievable and would benefit programmers.
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.