<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<title>Parallelism PDTS Comment Responses</title>
</head>
<body>
<table summary="Identifying information for this document.">
	<tr>
                <th>Doc. No.:</th>
                <td>WG21/N4275</td>
        </tr>
	<tr>
                <th>Date:</th>
                <td>2014-11-07</td>
        </tr>
        <tr>
                <th>Reply to:</th>
                <td>Hans-J. Boehm</td>
        </tr>
        <tr>
                <th>Email:</th>
                <td><a href="mailto:hboehm@google.com">hboehm@google.com</a></td>
        </tr>
</table>
	
<h1>N4275: Parallelism PDTS Comment Responses</h1>
<p>
<b>CH 1: Resurrect explicit permission for implementation-defined execution policies</b>
<p>
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:
<p>
<blockquote>
[Note: This provision reserves the privilege of creating non-standard execution policies to the library
implementation. --end note]
</blockquote>
<b>DE 1: Consider N4167</b>
<p>
Adopt N4276, augmented with scans.
<p>
<b>US 1: Execution policy definition</b>
<p>
Change 2.1:
<blockquote>
<p>
...indicates <ins>the kinds of parallelism allowed in the execution of</ins>
<del>to</del> an algorithm <del>whether it is allowed to execute in parallel</del>
and expresses the <ins>resulting</ins> requirements on the element access functions.
</blockquote>
<p>
<b>US 2: Don't necessarily want all exceptions</b>
<p>
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.
<p>
<b>US 3: Elemental access functions can
interrupt user code:</b>
<p>
Change 4.1.2p3 as follows:

<blockquote>
<p>
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 <del>unspecified threads</del><ins>either the invoking thread
or in a thread implicitly created by the library to support parallel algorithm
execution</ins>.<del>, and</del>
<ins>Any such invocations executing in the same thread are</ins> indeterminately sequenced
<del>within each thread</del><ins>with respect to each other</ins>. [ <i>Note:</i>
It is the
caller's responsibility to ensure correctness, for example that the invocation does
not introduce data races or deadlocks. -- <i> end note</i> ]
</blockquote>
<p>
<b>US 4: Similar to N4167</b>
<p>
Accepted as above.
<p>
<b>JP 1: Mistake in example</b>
<p>
Editorial.  Good catch. Will be fixed.
<p>
<b>JP 2: Add vector execution policy</b>
<p>
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.
<p>
<b>JP 3: List vectorization-safe functions</b>
<p>
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.
<p>
<b>JP 4: Arguments for execution policy for scan and reduce</b>
</p>
<p>
No change needed.  It is already implied by existing wording.
</p>
<p>
<b><del>Change requested via paper, without official NB comment:<del></b>
<p>
<del>We also voted to add N4157, which had unanimous support, improving consensus.
Solves a problem uncovered by multiple implementors.</del>

</body>
</html>
