Apply D4070

Author: jaredhoberock

algorithms.html

@@ -78,14 +78,45 @@ <h1>Effect of execution policies on algorithm execution</h1>
       <p>
         The applications of function objects in parallel algorithms invoked with an execution policy
         of type <code>parallel_vector_execution_policy</code> are permitted to execute in an unordered fashion
-        in unspecified threads, and unsequenced within each thread.
+        in unspecified threads, and unsequenced <ins>with respect to one another</ins> within each thread.
+
         <cxx-note>
           This means that multiple function object invocations may be interleaved on a single thread.
-        </cxx-note>
+        </cxx-note><pre>
+</pre>
+
+        <del>
         <cxx-note>
           As a consequence, function objects governed by the <code>parallel_vector_execution_policy</code>
           policy must not synchronize with each other. Specifically, they must not acquire locks.
         </cxx-note>
+        </del>
+        <ins>
+        <cxx-note>
+          <ins>This overrides the usual guarantee from the C++ standard, Section 1.9 [intro.execution] that
+          function executions do not interleave with one another.</ins>
+        </cxx-note>
+        </ins>
+        <pre>
+</pre>
+        
+        <ins>
+          Since <code>parallel_vector_execution_policy</code> allows the execution of such function objects to be
+          interleaved on a single thread, synchronization, including the use of mutexes, risks deadlock. Thus the
+          synchronization with <code>parallel_vector_execution_policy</code> is restricted as follows:<pre>
+</pre>
+
+          A standard library function is <em>vectorization-unsafe</em> if it is specified to synchronize with
+          another function invocation, or another function invocation is specified to synchronize with it, and if
+          it is not a memory allocation or deallocation function. Vectorization-unsafe standard library functions
+          may not be invoked by user code called from <code>parallel_vector_execution_policy</code> algorithms.<pre>
+</pre>
+
+          <cxx-note>
+            Implementations must ensure that internal synchronization inside standard library routines does not
+            induce deadlock.
+          </cxx-note>
+        </ins>
       </p>
 
       <cxx-example><pre>

parallelism-ts.html

@@ -1560,21 +1560,54 @@ <h1>Contents</h1>
       <p para_num="4" id="parallel.alg.general.exec.4">
         The applications of function objects in parallel algorithms invoked with an execution policy
         of type <code>parallel_vector_execution_policy</code> are permitted to execute in an unordered fashion
-        in unspecified threads, and unsequenced within each thread.
+        in unspecified threads, and unsequenced <ins>with respect to one another</ins> within each thread.
+
         <cxx-note><span class="nowrap">[ <em>Note:</em></span>
 
           This means that multiple function object invocations may be interleaved on a single thread.
 
     <span class="nowrap">— <em>end note</em> ]</span>
-  </cxx-note>
+  </cxx-note></p><pre></pre>
+
+        <del>
         <cxx-note><span class="nowrap">[ <em>Note:</em></span>
 
           As a consequence, function objects governed by the <code>parallel_vector_execution_policy</code>
           policy must not synchronize with each other. Specifically, they must not acquire locks.
 
     <span class="nowrap">— <em>end note</em> ]</span>
   </cxx-note>
-      </p>
+        </del>
+        <ins>
+        <cxx-note><span class="nowrap">[ <em>Note:</em></span>
+    
+          <ins>This overrides the usual guarantee from the C++ standard, Section 1.9 [intro.execution] that
+          function executions do not interleave with one another.</ins>
+        
+    <span class="nowrap">— <em>end note</em> ]</span>
+  </cxx-note>
+        </ins>
+        <pre></pre>
+        
+        <ins>
+          Since <code>parallel_vector_execution_policy</code> allows the execution of such function objects to be
+          interleaved on a single thread, synchronization, including the use of mutexes, risks deadlock. Thus the
+          synchronization with <code>parallel_vector_execution_policy</code> is restricted as follows:<pre></pre>
+
+          A standard library function is <em>vectorization-unsafe</em> if it is specified to synchronize with
+          another function invocation, or another function invocation is specified to synchronize with it, and if
+          it is not a memory allocation or deallocation function. Vectorization-unsafe standard library functions
+          may not be invoked by user code called from <code>parallel_vector_execution_policy</code> algorithms.<pre></pre>
+
+          <cxx-note><span class="nowrap">[ <em>Note:</em></span>
+    
+            Implementations must ensure that internal synchronization inside standard library routines does not
+            induce deadlock.
+          
+    <span class="nowrap">— <em>end note</em> ]</span>
+  </cxx-note>
+        </ins>
+      <p para_num="5" id="parallel.alg.general.exec.5"></p>
 
       <cxx-example>
 
@@ -1613,12 +1646,12 @@ <h1>Contents</h1>
     <span class="nowrap">— <em>end note</em> ]</span>
   </cxx-note>
 
-      <p para_num="5" id="parallel.alg.general.exec.5">
+      <p para_num="6" id="parallel.alg.general.exec.6">
         Algorithms invoked with an execution policy object of type <code>execution_policy</code>
         execute internally as if invoked with the contained execution policy object.
       </p>
 
-      <p para_num="6" id="parallel.alg.general.exec.6">
+      <p para_num="7" id="parallel.alg.general.exec.7">
         The semantics of parallel algorithms invoked with an execution policy object of
         implementation-defined type are implementation-defined.
       </p>