C++ in Koln

The summer 2019 WG21 C++ Committee meeting was held in Cologne, Germany during the week of July 13. As usual,
Red Hat sent three representatives, Jason Merrill in the Core Working Group (CWG), Jonathan Wakely in the Library Working Group (LWG), and myself in the Concurrency and Parallelism Study Group (SG1). This rather late report covers the Cologne SG1 session and looks ahead to some revised papers from that meeting, which are scheduled for the fall meeting in Belfast, Northern Ireland, for the first week of November 2019.

C++20 Synchronization Library

Monday started as usual after the main plenary session. SG1 started the week by reviewing some non-controversial
additions to C++20 synchronization primitives. The first of these papers was p1633R0 "Amendments to the C++20
Synchronization Library," which dealt some minor issues discovered during wording review of the C++20
Synchronization Library (p1135R4). The changes were applied to R5 of the paper, and SG1 voted to forward p1135R5
to LWG. Next up were p1643R0 and p1644R0, which propose to add wait/notify functionality to atomic_ref and
atomic, respectively. SG1 voted to forward both of these papers to the Library Evolution Working Group (LEWG).
The final paper before lunch was p0943R2, which concerns supporting C atomics in C++. SG1 voted to let the paper
proceed without needing to return for further review.

After the break, SG1 took up the subject of stackful co-routines (aka "fibers") with two papers:

  • P1520 "Response to response to "Fibers under the magnifying glass."" This paper seeks to clarify some aspects of the distinction between stackless co-routines and stackful fibers.
  • P0876 "fiber_context - fibers without scheduler." This is the latest (R6) paper in the series of proposals to bring fibers to the C++ standard. SG1 consensus was that P0876 needs changes to proceed. Further discussion on Friday reached agreement to target a Technical Specification as a ship vehicle for the proposal with the requested changes applied.


Next, it was on to everyone's favorite topic: Executors. The first paper P1525 "One-Way execute is a Poor Basis Operation." This paper argues in favor of the previous proposal for Executor Sender/Receiver as described in P1341 as the basis operation(s) supported by Executors, with other operations built in terms of senders and receivers, as opposed to P0443's OneWayExecutor concept. The SG1 presentation and subsequent discussion were primarily to inform Tuesday's discussions on p0443. The last paper of the day was P1738 "The Executor Concept Hierarchy Needs a Single Root." This paper seeks to argue that, because P0443's Executor concepts and mechanism for adding new concepts don't form a subsumption hierarchy, it's difficult to design generic components that accept executors. As with P1525, this was an informational presentation to inform Tuesday's discussions on P0443.

Tuesday morning, SG1 kicked off by reviewing P1068 "Vector API for random number generation." This paper
proposes to add SIMD support for random number generation. The discussion led to weak consensus that such a facility should produce a SIMD type as described in N4796 "Technical Specification for C++ Extensions for Parallelism." A revision of this paper will likely be discussed at the fall WG21 meeting.

Next up was P1367 "Not All Agents Have TLS." This paper proposes standardizing the existing practice of thread_local, as the reality of TLS usage is much more complicated than the wording in the Standard even allows us to explain. This is a rather complicated topic and SG1 had an extensive discussion on the issues, but no straw polls were taken at this meeting.

Tuesday afternoon, SG1 resumed discussion on Executors with P1658 "Suggestions for Consensus on Executors." This paper proposes to modify the executors model as described by P0443 to increase consensus in the hope that executors are merged with C++23 as planned. The compromise seeks to essentially create a singly rooted executor concept hierarchy and add support for customization of bulk_execute as well as introducing the Sender/Receiver concepts. The main point of contention remaining from the compromise is error handling.

We then discussed P1791 "Evolution of the P0443 Unified Executors Proposal to accommodate new requirements." The central premise of this paper is the properties mechanism outlined in P0443 can support the requirements of P1660's sender/receiver model. Again, significant discussion time was spent on what sort of error channel(s) should be supported. Next, P1792 "Simplifying and generalising Sender/Receiver for asynchronous operations" argues that the API design approach of P1341 "Unifying Asynchronous APIs in C++ Standard Library" presents problems with usability, flexibility, and efficiency compared to existing practice. No straw polls were taken; significant differences of opinion remain. The last paper of the day was P1660. After extensive discussion, SG1 voted to apply P1658's proposed changes to P0443, and that it would be "tolerable'" to ship error handling as in P1660. There was no consensus to proceed with error
handling as in P1791.

Memory model topics

Wednesday, SG1 turned its attention to all things memory model, starting with an update on P1217 "Out-of-thin-air, revisited, again." Next up, P1780 "Modular Relaxed Dependencies: A new approach to the Out-Of-Thin-Air Problem." Next, SG1 reviewed P1478R0 "Byte-wise atomic memcpy," which was presented as a draft at the Spring 2019 meeting and essentially looks to codify what most memcpy implementations already do. The shipping vehicle is likely a Technical Specification.

Wednesday afternoon, SG1 reviewed P1116 "Re-Gaining Exclusive Ownership from shared_ptrs," which is a proposal to add a "lock_exclusive()" operation to shared_ptr. SG1 determined it is implementable but not without ABI breakage, and they don't like the name of the operation. Next up, we reviewed P1726 "Pointer lifetime-end zap." This paper seeks to reconcile what the Standard says about the state of pointer after an object's lifetime has ended, with well-known algorithms that rely on being able to perform certain operations on pointers whose lifetimes have ended. There are various suggestions to address this issue, but no conclusions were reached at this meeting.

Next, we looked at P0940 "Concurrency TS is growing: Concurrent Utilities and Data Structures" and P1445 "Concurrency TS: to update or not update." The discussion of these papers mostly had to do with timing of issuing a new Technical Specification and what language standard it should be based on. From here, the discussion moved on to "Clarifying atomic<thread::id>::compare_exchange_*" (P1801). SG1 voted to approve the proposed resolution presented in the paper.

Low-level I/O and more executors

Thursday morning, SG1 considered a pair of related papers that deal with supporting low-level IO facilities and the ability to detach objects, transport them elsewhere, and resume the object lifetime. The papers were P1031 "Low-level file i/o library" and P1631 "Object detachment and attachment." The scope of these papers is quite large, even to just survey the issues, and SG1 determined that these proposals fall squarely in SG1's remit. Next SG1 considered
P0652 "Concurrent associative data structure with unsynchronized view," which had been updated based on SG1's guidance at the Spring 2019 meeting. SG1 discussed the various issues with such a datatype, but no straw polls were taken. Next SG1 looked at P1761 "Concurrent map customization options." These concurrent data structure papers are likely headed to a Technical Specification.

On Thursday afternoon, SG1 reviewed a handful of executor-related papers, starting with P1019 "Integrating Executors with Parallel Algorithms." Next was P0797R2 "Handling Concurrent Exceptions with Executors," followed by P1436R0 "Executor properties for affinity-based execution." There was general agreement that executors should support some form of error handling facility, as not all agents support C++ exceptions.

Friday papers

SG1 started Friday morning looking at P1382 "volatile_load<T> and volatile_store<T>," which is related to P1152 "Deprecating volatile." Next up was P1750 "A Proposal to Add Process Management to the C++ Standard Library." The proposal is based on the boost.process library, which provides cross-platform process management functionality, with a lot of discussion about how to support this within the standard. A new version of P1750 is available in the pre-Belfast meeting and is likely to be on SG1's agenda again. The last paper of the morning was P1108 "web_view," which proposes a web_view facility for the C++ standard library that leverages existing web standards and technology. A new version of P1108 is in the pre-Belfast mailing and is likely to be on SG1's agenda again.

Friday afternoon, SG1 reviewed P1795 "System topology discovery for heterogeneous and distributed computing." A new revision of this paper is available in the pre-Belfast meeting and is likely to be on SG1's agenda again. The last paper SG1 discussed in Cologne was P0642 "The Concurrent Invocation Library." The aim of this paper is to provide structural support for invoking multiple operations concurrently in C++. SG1's feedback was to review P1660 and come back with a new version of the paper, which is part of the pre-Belfast meeting and is likely to be reviewed again.

Last updated: July 1, 2020