Doc. No.: | WG21/N4275 |
---|---|
Date: | 2014-11-07 |
Reply to: | Hans-J. Boehm |
Email: | hboehm@google.com |
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]DE 1: Consider N4167
Adopt N4276, augmented with scans.
US 1: Execution policy definition
Change 2.1:
...indicates the kinds of parallelism allowed in the execution of
toan algorithmwhether it is allowed to execute in paralleland 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., andAny such invocations executing in the same thread are indeterminately sequencedwithin 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.