March 2018 ISO C++ Meeting Trip Report (SG1: Concurrency and Parallelism)

This year’s Winter ISO C++ Standard Committee meeting was held in March in Jacksonville, Florida. A number of larger features, for which there is substantial interest but which are also difficult to get right, were discussed:

Concepts, along with Concept types from the Ranges TS; see P0898 and n4685

Modules; see n4689

Coroutines; see n4723

Networking; see n4711

Executors; see p0443

Jason Merrill’s recently published trip report covers the core language topics. This report focuses on the topics of interest to the Concurrency and Parallelism Study Group (SG1). The “big ticket” items discussed in SG1 during the week were:

Executors

Networking

Coroutines

Futures

Much of the discussion involved how Executors interact with Networking and Coroutines. Separately there is an effort to bring new types similar to std::future to the Standard and determine what impact, if any, that work has on Executors.

Executors

The Executors paper’s authors and SG1 are fairly happy with the state of the current proposal. The LEWG discussion centered mainly around “how would you use this API?” The Executors proposal authors plan to submit papers for Rapperswil addressing the usage of the executors interface with existing and proposed related features of the standard library (networking, parallel algorithms, std::async , etc.) in order to advance the LEWG discussions.

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

Coroutines

The SG1 discussion around Coroutines largely centered on whether or not the Coroutines language facility had any dependency on Executors. The decision was that it doesn’t, but there was a desire to see more concrete examples of library facilities including those dependent on Executors using Coroutines. There was additional EWG discussion around this proposal. Google has experimented with the Coroutines TS and has reported several limitations and points where it thinks the features in the TS can be improved. The Coroutines proposal did not move to the C++20 IS at this meeting. Additional papers are expected for the June meeting in Rapperswil.

Networking

SG1 decided that Networking was dependent on Executors, and advancing Networking without proper integration with Executors would yield an unsatisfactory result.

Futures

The current std::future / std::promise pair is a fairly heavyweight construct that doesn’t map well to other kinds of executors (for example, GPGPUs). Other executor-like libraries expose lighter future concepts that are “executor-aware.” One outstanding question was whether Executors are dependent on specifying these new Future types. The Executors proposal authors agreed that Executors are not dependent on this work, but that since there is substantial overlap in the authorship of the proposals, the Executors authors will proceed with the assumption that when the work on a new Futures proposal is published it will just “do the right thing” with respect to Executors.

At the Saturday Plenary, the SG1 Chair presented this synopsis of the week’s discussions:

IS’20 ( barely possible )

Executors

Networking

IS’23

Executors

Networking

Additional algorithm policies

Revised Futures

Better async programming support

New Features

Several smaller new features were voted out of SG1 for the C++20 draft standard at this meeting:

Fixing atomic initialization, see: p0883.

This specifies atomic<T> to have a default initialized value of T{} , rather than the current uninitialized behavior.

This specifies to have a default initialized value of , rather than the current uninitialized behavior. The Curious Case of Padding Bits, Featuring Atomic Compare-and-Exchange; see p0528.

The crux of the issue is that an atomic CAS observes the bit pattern of the type being operated on, and that type will include padding bits if it’s a struct . This is currently broken, but it should “just work.” EWG’s guidance was to fix this with compiler magic. There was a fair bit of discussion on this topic and there will be some revised wording in the post-meeting mailing as a result.

The crux of the issue is that an atomic CAS observes the bit pattern of the type being operated on, and that type will include padding bits if it’s a . This is currently broken, but it should “just work.” EWG’s guidance was to fix this with compiler magic. There was a fair bit of discussion on this topic and there will be some revised wording in the post-meeting mailing as a result. Support C atomics in C++; see p0943.

The goal here is to make C++ code that includes C atomic definitions work.

The goal here is to make C++ code that includes C atomic definitions work. Revising the C++ Memory Model; see: p0668.

The paper proposes to address issues that have been found subsequent to publishing C++11’s

memory model that affect Power, Arm, and certain GPU architectures.

The paper proposes to address issues that have been found subsequent to publishing C++11’s memory model that affect Power, Arm, and certain GPU architectures. Efficient waiting for C++20; see p0514.

Support for efficient atomic waiting and semaphores.

Support for efficient atomic waiting and semaphores. Improving atomic_flag ; see d0995.

This fell out of discussion earlier in the week on p0514r3. The current atomic_flag is not particularly useful, and a proposal to deprecate it was mooted. After ongoing discussions during the week, a new proposal came out that improves the existing atomic_flag . This is small enough that it is likely to see the light of day in C++20.

; see d0995. This fell out of discussion earlier in the week on p0514r3. The current is not particularly useful, and a proposal to deprecate it was mooted. After ongoing discussions during the week, a new proposal came out that improves the existing . This is small enough that it is likely to see the light of day in C++20. Concurrency TS v2.

There was consensus to move a couple of long-languishing papers on distributed counters and concurrent queues to LEWG for inclusion in a Concurrency TS v2. See:

Distributed Counters: P0261

Concurrent Queues: P0260