Several Red Hat engineers attended the JTC1/SC22/WG21 C++ Standards Committee meetings in July 2017. This post focuses on the sessions of SG1, the study group on parallelism and concurrency. We discussed several synchronization-related proposals, improvements for futures, and, of course, executors. Also, I proposed a few steps that the SG1 community could take to get more efficient in how it conducts its work, which are all inspired by how successful open source projects work.
Most of the proposals we discussed at this meeting were related to concurrency. Latches were moved into the draft for the next version of the standard, and we made progress on semaphores, hazard pointers, and deferred reclamation. We discussed bugs in the memory model that, however, seem to arise only in arguably odd pieces of synchronization code or are just bugs in the specification but not in actual implementations. The trade-off for fixing the former seems to be between (1) decreasing performance of common synchronization code and (2) changing the behavior guaranteed by the memory model for those truly odd cases; it seems likely that we will accept the latter because the former would decrease performance too much for too many users. Any change to the memory model should be accompanied by good explanations of the change and an update of the important tools (e.g., cppmem), in my opinion.
The role of futures, or std::future, in particular, is increasing in C++ due to recent proposals related to asynchronous execution, and due to more facilities that can spawn work tasks (e.g., executors) and thus need to return a handle to such work that may not yet have completed yet. However, std::future seems to not be quite the best fit for all these uses, and we discussed several proposals that explain problems in the design or present different interfaces for futures.
I presented a particular problem of futures when combined with threads of execution that are run with only weaker forward progress guarantees (i.e., parallel or weakly parallel forward progress, as for example threads of execution spawned by the parallel algorithms in C++17 under certain execution policies). I argued that if a future is used to block on such weak-progress threads of execution, the blocking operation should use blocking with progress guarantee delegation. This ensures, informally, that dependencies on other work drive execution of that other work, which is a very useful property in my opinion -- it is also how the parallel algorithms can safely make use of threads with weak progress guarantees. However, current futures can be used both as (1) a means to express dependencies on other work and (2) as a synchronization mechanism, and blocking with progress guarantee delegation isn't meant for the latter. This is yet another indication that a re-design of futures could be helpful so that these two different use cases can be distinguished.
Executors were, of course, also discussed in the meeting, in particular, a new proposal regarding how to simplify the previously proposed unified interface. SG1 is making progress regarding executors and is getting closer to agreeing on a design, but I can't report that we would have consensus on a design yet, unfortunately.
We ended the week by discussing how we could improve the way that SG1 operates and how we collaborate with each other and other contributors. I have been arguing for doing things that successful open source projects do: SG1, its contributors, and our users are effectively a community, and even though the C++ standard is not the same as a codebase with an open-source license, we do want to and need to collaborate effectively and efficiently to be successful and serve our users well. Even just considering SG1 and regular contributors, there are several things we can do to improve collaboration, which should eventually lead to SG1 being more productive, and thus users likely getting good programming abstractions at a faster pace. Specific actions I suggested where (1) making the reasoning behind the design of the programming abstractions we specify more accessible, in particular for contributors that cannot participate full time, (2) increasing our focus on consensus building, and (3) enabling that more work can be done between meetings (i.e., in the spirit of continuous integration). I'm hopeful that we can agree on doing at least some of these things, and I'm looking forward to any improvements.
Whether you are new to Containers or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.
Last updated: August 23, 2017