Skip to content

Commit 8a31d7b

Browse files
jaredhoberockjaredhoberock
committed
Prepare documents for pre-Albuquerque mailing
1 parent d37bb9c commit 8a31d7b

6 files changed

+388
-17
lines changed

‎README.md

+12-10
Original file line numberDiff line numberDiff line change
@@ -1,26 +1,28 @@
1-
Document Number: N4670
2-
Date: 2017-06-19
1+
Document Number: N4699
2+
Date: 2017-10-16
33
Revises:
44
Project: Programming Language C++
55
Project Number: TS 19570
66
Reply-to: Jared Hoberock
77
NVIDIA Corporation
88
[email protected]
99

10-
# Parallelism TS Editor's Report, pre-Toronto mailing
10+
# Parallelism TS Editor's Report, pre-Albuquerque mailing
1111

12-
N4669 is the proposed working draft of Parallelism TS Version 2. It contains editorial changes to the Parallelism TS to make it consistent with new ISO directives concerning "Scope", "Normative references", and "Terms and definitions" clauses.
12+
N4698 is the proposed working draft of Parallelism TS Version 2. It contains changes to the Parallelism TS as directed by the committee at the Toronto meeting, and editorial changes.
1313

14-
N4669 updates the previous draft, N4579, published in the pre-Jacksonville mailing.
14+
N4698 updates the previous draft, N4669, published in the pre-Toronto mailing.
1515

1616
# Technical Changes
1717

18-
None.
18+
* Apply P0076R4 - Vector and Wavefront Policies.
1919

2020
# Editorial Changes
2121

22-
* Introduced new Clause 1 - Scope
23-
* Introduced new Clause 2 - Normative references
24-
* Introduced new Clause 3 - Terms and definitions
25-
* Incremented the numbers of all existing clauses
22+
* Reformat Table 1 - Feature Test Macro(s), to match the style of the Library Fundamentals TS.
23+
24+
# Notes
25+
26+
* The pre-existing content of N4698 has not yet been harmonized with C++17. As a result, this content is named and namespaced inconsistently with the newly applied content of P0076R4. We anticipate that these inconsistencies will be harmonized by a future revision.
27+
* N4698 contains forward references to `for_loop` and `for_loop_strided`. We anticipate their introduction in a future revision.
2628

‎algorithms.html

+283
Original file line numberDiff line numberDiff line change
@@ -88,6 +88,37 @@ <h1>Effect of execution policies on algorithm execution</h1>
8888
incremented correctly.
8989
</cxx-example>
9090

91+
<ins>
92+
<p>
93+
The invocations of element access functions in parallel algorithms invoked with an
94+
execution policy of type <code>unsequenced_policy</code> are permitted to execute
95+
in an unordered fashion in the calling thread, unsequenced with respect to one another
96+
within the calling thread.
97+
98+
<cxx-note>
99+
This means that multiple function object invocations may be interleaved on a single thread.
100+
</cxx-note>
101+
<pre>
102+
</pre>
103+
104+
<cxx-note>
105+
This overrides the usual guarantee from the C++ standard, Section 1.9 [intro.execution] that
106+
function executions do not interleave with one another.
107+
</cxx-note>
108+
</p>
109+
</ins>
110+
111+
<ins>
112+
<p>
113+
The invocations of element access functions in parallel algorithms invoked with an
114+
executino policy of type <code>vector_policy</code> are permitted to execute
115+
in an unordered fashion in the calling thread, unsequenced with respect to one another
116+
within the calling thread, subject to the sequencing constraints of wavefront application
117+
(<cxx-ref to="parallel.alg.general.wavefront"></cxx-ref>) for the last argument to
118+
<code>for_loop</code> or <code>for_loop_strided</code>.
119+
</p>
120+
</ins>
121+
91122
<p>
92123
The invocations of element access functions in parallel algorithms invoked with an execution
93124
policy of type <code>parallel_vector_execution_policy</code>
@@ -163,6 +194,107 @@ <h1>Effect of execution policies on algorithm execution</h1>
163194
</p>
164195
</cxx-section>
165196

197+
<cxx-section id="parallel.alg.general.wavefront">
198+
<h1>Wavefront Application</h1>
199+
<ins>
200+
<p>
201+
For the purposes of this section, an <i>evaluation</i> is a value computation or side effect of
202+
an expression, or an execution of a statement. Initialization of a temporary object is considered a
203+
subexpression of the expression that necessitates the temporary object.
204+
</p>
205+
206+
<p>
207+
An evaluation A <i>contains</i> an evaluation B if:
208+
209+
<ul>
210+
<li>A and B are not potentially concurrent ([intro.races]); and</li>
211+
<li>the start of A is the start of B or the start of A is sequenced before the start of B; and</li>
212+
<li>the completion of B is the completion of A or the completion of B is sequenced before the completion of A.</li>
213+
</ul>
214+
215+
<cxx-note>This includes evaluations occurring in function invocations.</cxx-note>
216+
</p>
217+
218+
<p>
219+
An evaluation A is <i>ordered before</i> an evaluation B if A is deterministically
220+
sequenced before B. <cxx-note>If A is indeterminately sequenced with respect to B
221+
or A and B are unsequenced, then A is not ordered before B and B is not ordered
222+
before A. The ordered before relationship is transitive.</cxx-note>
223+
</p>
224+
225+
<p>
226+
For an evaluation A ordered before an evaluation B, both contained in the same
227+
invocation of an element access function, A is a <i>vertical antecedent</i> of B if:
228+
229+
<ul>
230+
<li>there exists an evaluation S such that:
231+
<ul>
232+
<li>S contains A, and</li>
233+
<li>S contains all evaluations C (if any) such that A is ordered before C and C is ordered before B,</li>
234+
<li>but S does not contain B, and</li>
235+
</ul>
236+
</li>
237+
<li>
238+
control reached B from A without executing any of the following:
239+
<ul>
240+
<li>a <code>goto</code> statement or <code>asm</code> declaration that jumps to a statement outside of S, or</li>
241+
<li>a <code>switch</code> statement executed within S that transfers control into a substatement of a nested selection or iteration statement, or</li>
242+
<li>a <code>throw</code> <cxx-note>even if caught</cxx-note>, or</li>
243+
<li>a <code>longjmp</code>.
244+
</ul>
245+
</li>
246+
</ul>
247+
248+
<cxx-note>
249+
Vertical antecedent is an irreflexive, antisymmetric, nontransitive relationship between two evaluations.
250+
Informally, A is a vertical antecedent of B if A is sequenced immediately before B or A is nested zero or
251+
more levels within a statement S that immediately precedes B.
252+
</cxx-note>
253+
</p>
254+
255+
<p>
256+
In the following, <i>X<sub>i</sub></i> and <i>X<sub>j</sub></i> refer to evaluations of the <i>same</i> expression
257+
or statement contained in the application of an element access function corresponding to the i<sup>th</sup> and
258+
j<sup>th</sup> elements of the input sequence. <cxx-note>There might be several evaluations <i>X<sub>k</sub></i>,
259+
<i>Y<sub>k</sub></i>, etc. of a single expression or statement in application <i>k</i>, for example, if the
260+
expression or statement appears in a loop within the element access function.</cxx-note>
261+
</p>
262+
263+
<p>
264+
<i>Horizontally matched</i> is an equivalence relationship between two evaluations of the same expression. An
265+
evaluation B<sub>i</sub> is <i>horizontally matched</i> with an evaluation B<sub>j</sub> if:
266+
267+
<ul>
268+
<li>both are the first evaluations in their respective applications of the element access function, or</li>
269+
<li>there exist horizontally matched evaluations A<sub>i</sub> and A<sub>j</sub> that are vertical antecedents of evaluations B<sub>i</sub> and B<sub>j</sub>, respectively.
270+
</ul>
271+
272+
<cxx-note>
273+
<i>Horizontally matched</i> establishes a theoretical <i>lock-step</i> relationship between evaluations in different applications of an element access function.
274+
</cxx-note>
275+
</p>
276+
277+
<p>
278+
Let <i>f</i> be a function called for each argument list in a sequence of argument lists.
279+
<i>Wavefront application</i> of <i>f</i> requires that evaluation A<sub>i</sub> be sequenced
280+
before evaluation B<sub>i</sub> if i &lt; j and and:
281+
282+
<ul>
283+
<li>A<sub>i</sub> is sequenced before some evaluation B<sub>i</sub> and B<sub>i</sub> is horizontally matched with B<sub>j</sub>, or</li>
284+
<li>A<sub>i</sub> is horizontally matched with some evaluation A<sub>j</sub> and A<sub>j</sub> is sequenced before B<sub>j<sub>.</li>
285+
</ul>
286+
287+
<cxx-note>
288+
<i>Wavefront application</i> guarantees that parallel applications i and j execute such that progress on application j never gets <i>ahead</i> of application i.
289+
</cxx-note>
290+
291+
<cxx-note>
292+
The relationships between A<sub>i</sub> and B<sub>i</sub> and between A<sub>j</sub> and B<sub>j</sub> are <i>sequenced before</i>, not <i>vertical antecedent</i>.
293+
</cxx-note>
294+
</p>
295+
</ins>
296+
</cxx-section>
297+
166298
<cxx-section id="parallel.alg.overloads">
167299
<h1><code>ExecutionPolicy</code> algorithm overloads</h1>
168300

@@ -379,6 +511,20 @@ <h1>Header <code>&lt;experimental/algorithm&gt;</code> synopsis</h1>
379511
InputIterator for_each_n(ExecutionPolicy&amp;&amp; exec,
380512
InputIterator first, Size n,
381513
Function f);
514+
515+
<ins>namespace execution {
516+
<cxx-ref insynopsis="" to="parallel.alg.novec"></cxx-ref>
517+
template&lt;class F&gt;
518+
auto no_vec(F&amp;&amp; f) noexcept -&gt; decltype(std::forward&lt;F&gt;(f)());
519+
520+
<cxx-ref insynopsis="" to="parallel.alg.ordupdate.class"></cxx-ref>
521+
template&lt;class T&gt;
522+
class ordered_update_t;
523+
524+
<cxx-ref insynopsis="" to="parallel.alg.ordupdate.func"></cxx-ref>
525+
template&lt;class T&gt;
526+
ordered_update_t&lt;T&gt; ordered_update(T&amp; ref) noexcept;
527+
}</ins>
382528
}
383529
}
384530
}
@@ -487,6 +633,143 @@ <h1>For each</h1>
487633
</cxx-notes>
488634
</cxx-function>
489635
</cxx-section>
636+
637+
<cxx-section id="parallel.alg.novec">
638+
<h1>No vec</h1>
639+
640+
<ins>
641+
<cxx-function>
642+
<cxx-signature>template&lt;class F&gt;
643+
auto no_vec(F&amp;&amp; f) noexcept -&gt; decltype(std::forward&lt;F&gt;(f)());</cxx-signature>
644+
645+
<cxx-effects>
646+
Evaluates <code>std::forward&gt;F&lt;(f)()</code>. When invoked within an element access function
647+
in a parallel algorithm using <code>vector_policy</code>, if two calls to <code>no_vec</code> are
648+
horizontally matched within a wavefront application of an element access function over input
649+
sequence S, then the execution of <code>f</code> in the application for one element in S is
650+
sequenced before the execution of <code>f</code> in the application for a subsequent element in
651+
S; otherwise, there is no effect on sequencing.
652+
</cxx-effects>
653+
654+
<cxx-returns>
655+
the result of <code>f</code>.
656+
</cxx-returns>
657+
658+
<cxx-remarks>
659+
If <code>f</code> returns a result, the result is ignored.
660+
</cxx-remarks>
661+
662+
<cxx-notes>
663+
If <code>f</code> exits via an exception, then <code>terminate</code> will be called, consistent
664+
with all other potentially-throwing operations invoked with <code>vector_policy</code> execution.
665+
666+
<cxx-example>
667+
<pre>extern int* p;
668+
for_loop(vec, 0, n[&amp;](int i) {
669+
y[i] +=y[i+1];
670+
if(y[i] &lt; 0) {
671+
no_vec([]{
672+
*p++ = i;
673+
});
674+
}
675+
});</pre>
676+
677+
The updates <code>*p++ = i</code> will occur in the same order as if the policy were <code>seq</code>.
678+
</cxx-example>
679+
</cxx-notes>
680+
</cxx-function>
681+
</ins>
682+
</cxx-section>
683+
684+
<cxx-section id="parallel.alg.ordupdate.class">
685+
<h1>Ordered update class</h1>
686+
687+
<ins>
688+
<pre>
689+
class ordered_update_t {
690+
T&amp; ref_; // exposition only
691+
public:
692+
ordered_update_t(T&amp; loc) noexcept
693+
: ref_(loc) {}
694+
ordered_update_t(const ordered_update_t&amp;) = delete;
695+
ordered_update_t&amp; operator=(const ordered_update_t&amp;) = delete;
696+
697+
template &lt;class U&gt;
698+
auto operator=(U rhs) const noexcept
699+
{ return no_vec([&amp;]{ return ref_ = std::move(rhs); }); }
700+
template &lt;class U&gt;
701+
auto operator+=(U rhs) const noexcept
702+
{ return no_vec([&amp;]{ return ref_ += std::move(rhs); }); }
703+
template &lt;class U&gt;
704+
auto operator-=(U rhs) const noexcept
705+
{ return no_vec([&amp;]{ return ref_ -= std::move(rhs); }); }
706+
template &lt;class U&gt;
707+
auto operator*=(U rhs) const noexcept
708+
{ return no_vec([&amp;]{ return ref_ *= std::move(rhs); }); }
709+
template &lt;class U&gt;
710+
auto operator/=(U rhs) const noexcept
711+
{ return no_vec([&amp;]{ return ref_ /= std::move(rhs); }); }
712+
template &lt;class U&gt;
713+
auto operator%=(U rhs) const noexcept
714+
{ return no_vec([&amp;]{ return ref_ %= std::move(rhs); }); }
715+
template &lt;class U&gt;
716+
auto operator&gt;&gt;=(U rhs) const noexcept
717+
{ return no_vec([&amp;]{ return ref_ &gt;&gt;= std::move(rhs); }); }
718+
template &lt;class U&gt;
719+
auto operator&lt;&lt;=(U rhs) const noexcept
720+
{ return no_vec([&amp;]{ return ref_ &lt;&lt;= std::move(rhs); }); }
721+
template &lt;class U&gt;
722+
auto operator&amp;=(U rhs) const noexcept
723+
{ return no_vec([&amp;]{ return ref_ &amp;= std::move(rhs); }); }
724+
template &lt;class U&gt;
725+
auto operator^=(U rhs) const noexcept
726+
{ return no_vec([&amp;]{ return ref_ ^= std::move(rhs); }); }
727+
template &lt;class U&gt;
728+
auto operator|=(U rhs) const noexcept
729+
{ return no_vec([&amp;]{ return ref_ |= std::move(rhs); }); }
730+
731+
auto operator++() const noexcept
732+
{ return no_vec([&amp;]{ return ++ref_; }); }
733+
auto operator++(int) const noexcept
734+
{ return no_vec([&amp;]{ return ref_++; }); }
735+
auto operator--() const noexcept
736+
{ return no_vec([&amp;]{ return --ref_; }); }
737+
auto operator--(int) const noexcept
738+
{ return no_vec([&amp;]{ return ref_--; }); }
739+
};
740+
</pre>
741+
742+
<p>
743+
An object of type <code>ordered_update_t&gt;T&lt;</code> is a proxy for an object of type T
744+
intended to be used within a parallel application of an element access function using a
745+
policy object of type <code>vector_policy</code>. Simple increments, assignments, and compound
746+
assignments to the object are forwarded to the proxied object, but are sequenced as though
747+
executed within a <code>no_vec</code> invocation.
748+
749+
<cxx-note>
750+
The return-value deduction of the forwarded operations results in these operations returning by
751+
value, not reference. This formulation prevents accidental collisions on accesses to the return
752+
value.
753+
</cxx-note>
754+
</p>
755+
</ins>
756+
</cxx-section>
757+
758+
<cxx-section id="parallel.alg.ordupdate.func">
759+
<h1>Ordered update function template</h1>
760+
<ins>
761+
762+
<cxx-function>
763+
<cxx-signature>template&lt;T&gt;
764+
ordered_update_t&lt;T&gt; ordered_update(T&amp; loc) noexcept;</cxx-signature>
765+
</cxx-function>
766+
767+
<cxx-returns>
768+
<code>{ loc }</code>.
769+
</cxx-returns>
770+
771+
</ins>
772+
</cxx-section>
490773
</cxx-section>
491774

492775
<cxx-section id="parallel.alg.numeric">

‎exceptions.html

+1-1
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ <h1>Exception reporting behavior</h1>
1414

1515
<ul>
1616
<li>
17-
If the execution policy object is of type <code>class parallel_vector_execution_policy</code>,
17+
If the execution policy object is of type <code><del>class </del>parallel_vector_execution_policy</code><ins>, <code>unsequenced_policy</code>, or <code>vector_policy</code></ins>,
1818
<code>std::terminate</code> shall be called.
1919
</li>
2020
<li>

0 commit comments

Comments
 (0)