P0502r0
Throwing out of a parallel algorithm terminates—but how?

Published Proposal,

This version:
http://wg21.link/P0502r0
Authors:
(Apple)
(Lawrence Berkeley National Laboratory)
(Sandia National Laboratory)
Audience:
SG1, LWG
Toggle Diffs:
Project:
ISO JTC1/SC22/WG21: Programming Language C++
Source:
github.com/jfbastien/papers/blob/master/source/P0502r0.bs

Abstract

The Committee approves of terminating if exceptions leave parallel algorithms, but where to mandate termination should be updated.

1. Background

The Standard was simplified in [P0394r4]: exceptions leaving parallel algorithms lead to std::terminate() being called. This matches the behavior of exceptions leaving main() as well as std::thread().

The following National Body comments from [P0488R0] were discussed in SG1 at Issaquah, along with [p0451r0]:

1.1. Straw Polls

The following straw polls were taken:

Straw Poll A: In 25.2.4 ❡2, have uncaught exception behavior be defined by ExecutionPolicy. In 20.19 define the behavior for the three standard policies in C++17 (seq, par, par_unseq) as terminate().

SF F N A SA
Many 7 1 1 0

⟹ Consensus to write a paper for this before the end of the week. Bryce, JF, and Carter will write it.

Straw Poll B: Do we want to rename the policies to reflect the fact that they call terminate() instead of throwing exceptions.

SF F N A SA
1 7 9 6 7

⟹ No consensus for change.

Straw Poll C: Beyond the changes from the first straw poll, additional changes are required.

SF F N A SA
2 0 10 11 6

⟹ No consensus for change.

1.2. Action

This paper follows the guidance from straw poll A: there is no behavior change, but the behavior is specified to allow future execution policies which exhibit different behavior.

2. Proposed Wording

Apply the following edits to section 15.5.1 ❡1 note, bullet 1.13:

15.5.1 The std::terminate() function [except.terminate]

  1. In some situations exception handling must be abandoned for less subtle error handling techniques. [ Note: These situations are:

[…]

(1.13) — for parallel algorithms whose ExecutionPolicy specify such behavior (20.19.4, 20.19.5, 20.19.6), when execution of an element access function (25.2.1) of a parallel algorithm exits via an exception (25.2.4), or

[…]

— end note ]

Apply the following edits to section 20.19:

20.19.4 Sequential execution policy [execpol.seq]

class execution::sequenced_policy { unspecified };
  1. The class execution::sequenced_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and require that a parallel algorithm’s execution may not be parallelized.

  2. During the execution of a parallel algorithm with the execution::sequenced_policy policy, if the invocation of an element access function exits via an uncaught exception, terminate() shall be called.

20.19.5 Parallel execution policy [execpol.par]

class execution::parallel_policy { unspecified };
  1. The class execution::parallel_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm’s execution may be parallelized.

  2. During the execution of a parallel algorithm with the execution::parallel_policy policy, if the invocation of an element access function exits via an uncaught exception, terminate() shall be called.

20.19.6 Parallel+Vector execution policy [execpol.vec]

class execution::parallel_unsequenced_policy { unspecified };
  1. The class execution::parallel_unsequenced_policy is an execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm’s execution may be parallelized and vectorized.

  2. During the execution of a parallel algorithm with the execution::parallel_unsequenced_policy policy, if the invocation of an element access function exits via an uncaught exception, terminate() shall be called.

Apply the following edits to section 25.2.4 [algorithms.parallel.exceptions] ❡2:

During the execution of a parallel algorithm, if the invocation of an element access function exits via an uncaught exception, the behavior is determined by the ExecutionPolicy. terminate() is called.

3. Acknowledgement

Thank you to all SG1 participants: David Sankel, Alisdair Meredith, Hartmut Kaiser, Pablo Halpern, Jared Hoberock, Michael Wong, Pete Becker. Special thanks to the scribe Paul McKenney.

References

Informative References

[P0394r4]
JF Bastien, Bryce Adelstein Lelbach. Hotel Parallelifornia: terminate() for Parallel Algorithms Exception Handling. 23 June 2016. URL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0394r4.html
[P0451R0]
Bryce Adelstein Lelbach, Alisdair Meredith. Future-Proofing Parallel Algorithms Exception Handling. 14 October 2016. URL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0451r0.html
[P0488R0]
Barry Hedquist. WG21 Working paper: NB Comments, ISO/IEC CD 14882. 18 October 2016. URL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0488r0.pdf