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.

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.
• 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.
• Support C atomics in C++; see p0943.
  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.
• Efficient waiting for C++20; see p0514.
  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.
• 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