N4275: Parallelism PDTS Comment Responses

CH 1: Resurrect explicit permission for implementation-defined execution policies

Editorially re-add note, Jared will handle. Clarification: We are not proposing to add back the previously deleted normative test, only the note. Replace paragraph 3 by the original wording:

[Note: This provision reserves the privilege of creating non-standard execution policies to the library implementation. --end note]

Adopt N4276, augmented with scans.

US 1: Execution policy definition

Change 2.1:

...indicates the kinds of parallelism allowed in the execution of to an algorithm whether it is allowed to execute in parallel and expresses the resulting requirements on the element access functions.

US 2: Don't necessarily want all exceptions

No consensus for a change. There was a feeling that any dropped execptions could result in losing the real cause of a failure. Implementors already have license to do this with an implementation-defined execution policy. Author of the comment is OK with that.

US 3: Elemental access functions can interrupt user code:

Change 4.1.2p3 as follows:

The invocations of element access functions in parallel algorithms invoked with an execution policy object of type parallel_execution_policy are permitted to execute in an unordered fashion in unspecified threadseither the invoking thread or in a thread implicitly created by the library to support parallel algorithm execution., and Any such invocations executing in the same thread are indeterminately sequenced within each threadwith respect to each other. [ Note: It is the caller's responsibility to ensure correctness, for example that the invocation does not introduce data races or deadlocks. -- end note ]

US 4: Similar to N4167

Accepted as above.

JP 1: Mistake in example

Editorial. Good catch. Will be fixed.

JP 2: Add vector execution policy

No consensus to pursue this for this TS. There is interest in looking at this for a future version of the TS. Detailed proposals welcome.

JP 3: List vectorization-safe functions

No consensus for change. The current text is precise and brief, though not the easiest to read. The alternative would be a very long list of vectorization-safe functions or a slightly shorter list of vectorization-unsafe functions, which would need to be amended by every future TS. Note that the current definition effectively expects that standard library functions with internal synchronization are executed serially if they are invoked from a vector context.

JP 4: Arguments for execution policy for scan and reduce

No change needed. It is already implied by existing wording.

Change requested via paper, without official NB comment:

We also voted to add N4157, which had unanimous support, improving consensus. Solves a problem uncovered by multiple implementors.