tmp/tmpebc452aa/{from.md → to.md}
RENAMED
|
@@ -71,13 +71,13 @@ different threads of execution.
|
|
| 71 |
|
| 72 |
Unless otherwise specified, function objects passed into parallel
|
| 73 |
algorithms as objects of type `Predicate`, `BinaryPredicate`, `Compare`,
|
| 74 |
`UnaryOperation`, `BinaryOperation`, `BinaryOperation1`,
|
| 75 |
`BinaryOperation2`, and the operators used by the analogous overloads to
|
| 76 |
-
these parallel algorithms that
|
| 77 |
-
|
| 78 |
-
|
| 79 |
they rely on the identity of the provided objects.
|
| 80 |
|
| 81 |
### Effect of execution policies on algorithm execution <a id="algorithms.parallel.exec">[[algorithms.parallel.exec]]</a>
|
| 82 |
|
| 83 |
Parallel algorithms have template parameters named `ExecutionPolicy`
|
|
@@ -97,16 +97,16 @@ argument is modified. — *end note*]
|
|
| 97 |
Unless otherwise stated, implementations may make arbitrary copies of
|
| 98 |
elements (with type `T`) from sequences where
|
| 99 |
`is_trivially_copy_constructible_v<T>` and
|
| 100 |
`is_trivially_destructible_v<T>` are `true`.
|
| 101 |
|
| 102 |
-
[*Note 2*: This implies that user-supplied function objects
|
| 103 |
-
|
| 104 |
-
|
| 105 |
-
|
| 106 |
-
|
| 107 |
-
|
| 108 |
|
| 109 |
The invocations of element access functions in parallel algorithms
|
| 110 |
invoked with an execution policy object of type
|
| 111 |
`execution::sequenced_policy` all occur in the calling thread of
|
| 112 |
execution.
|
|
@@ -118,18 +118,18 @@ The invocations of element access functions in parallel algorithms
|
|
| 118 |
invoked with an execution policy object of type
|
| 119 |
`execution::unsequenced_policy` are permitted to execute in an unordered
|
| 120 |
fashion in the calling thread of execution, unsequenced with respect to
|
| 121 |
one another in the calling thread of execution.
|
| 122 |
|
| 123 |
-
[*Note 4*: This means that multiple function object invocations
|
| 124 |
interleaved on a single thread of execution, which overrides the usual
|
| 125 |
guarantee from [[intro.execution]] that function executions do not
|
| 126 |
overlap with one another. — *end note*]
|
| 127 |
|
| 128 |
The behavior of a program is undefined if it invokes a
|
| 129 |
vectorization-unsafe standard library function from user code called
|
| 130 |
-
from
|
| 131 |
|
| 132 |
[*Note 5*: Because `execution::unsequenced_policy` allows the execution
|
| 133 |
of element access functions to be interleaved on a single thread of
|
| 134 |
execution, blocking synchronization, including the use of mutexes, risks
|
| 135 |
deadlock. — *end note*]
|
|
@@ -208,18 +208,18 @@ unordered fashion in unspecified threads of execution, and unsequenced
|
|
| 208 |
with respect to one another within each thread of execution. These
|
| 209 |
threads of execution are either the invoking thread of execution or
|
| 210 |
threads of execution implicitly created by the library; the latter will
|
| 211 |
provide weakly parallel forward progress guarantees.
|
| 212 |
|
| 213 |
-
[*Note 7*: This means that multiple function object invocations
|
| 214 |
interleaved on a single thread of execution, which overrides the usual
|
| 215 |
guarantee from [[intro.execution]] that function executions do not
|
| 216 |
overlap with one another. — *end note*]
|
| 217 |
|
| 218 |
The behavior of a program is undefined if it invokes a
|
| 219 |
vectorization-unsafe standard library function from user code called
|
| 220 |
-
from
|
| 221 |
|
| 222 |
[*Note 8*: Because `execution::parallel_unsequenced_policy` allows the
|
| 223 |
execution of element access functions to be interleaved on a single
|
| 224 |
thread of execution, blocking synchronization, including the use of
|
| 225 |
mutexes, risks deadlock. — *end note*]
|
|
|
|
| 71 |
|
| 72 |
Unless otherwise specified, function objects passed into parallel
|
| 73 |
algorithms as objects of type `Predicate`, `BinaryPredicate`, `Compare`,
|
| 74 |
`UnaryOperation`, `BinaryOperation`, `BinaryOperation1`,
|
| 75 |
`BinaryOperation2`, and the operators used by the analogous overloads to
|
| 76 |
+
these parallel algorithms that are formed by an invocation with the
|
| 77 |
+
specified default predicate or operation (where applicable) shall not
|
| 78 |
+
directly or indirectly modify objects via their arguments, nor shall
|
| 79 |
they rely on the identity of the provided objects.
|
| 80 |
|
| 81 |
### Effect of execution policies on algorithm execution <a id="algorithms.parallel.exec">[[algorithms.parallel.exec]]</a>
|
| 82 |
|
| 83 |
Parallel algorithms have template parameters named `ExecutionPolicy`
|
|
|
|
| 97 |
Unless otherwise stated, implementations may make arbitrary copies of
|
| 98 |
elements (with type `T`) from sequences where
|
| 99 |
`is_trivially_copy_constructible_v<T>` and
|
| 100 |
`is_trivially_destructible_v<T>` are `true`.
|
| 101 |
|
| 102 |
+
[*Note 2*: This implies that user-supplied function objects cannot rely
|
| 103 |
+
on object identity of arguments for such input sequences. If object
|
| 104 |
+
identity of the arguments to these function objects is important, a
|
| 105 |
+
wrapping iterator that returns a non-copied implementation object such
|
| 106 |
+
as `reference_wrapper<T>` [[refwrap]], or some equivalent solution, can
|
| 107 |
+
be used. — *end note*]
|
| 108 |
|
| 109 |
The invocations of element access functions in parallel algorithms
|
| 110 |
invoked with an execution policy object of type
|
| 111 |
`execution::sequenced_policy` all occur in the calling thread of
|
| 112 |
execution.
|
|
|
|
| 118 |
invoked with an execution policy object of type
|
| 119 |
`execution::unsequenced_policy` are permitted to execute in an unordered
|
| 120 |
fashion in the calling thread of execution, unsequenced with respect to
|
| 121 |
one another in the calling thread of execution.
|
| 122 |
|
| 123 |
+
[*Note 4*: This means that multiple function object invocations can be
|
| 124 |
interleaved on a single thread of execution, which overrides the usual
|
| 125 |
guarantee from [[intro.execution]] that function executions do not
|
| 126 |
overlap with one another. — *end note*]
|
| 127 |
|
| 128 |
The behavior of a program is undefined if it invokes a
|
| 129 |
vectorization-unsafe standard library function from user code called
|
| 130 |
+
from an `execution::unsequenced_policy` algorithm.
|
| 131 |
|
| 132 |
[*Note 5*: Because `execution::unsequenced_policy` allows the execution
|
| 133 |
of element access functions to be interleaved on a single thread of
|
| 134 |
execution, blocking synchronization, including the use of mutexes, risks
|
| 135 |
deadlock. — *end note*]
|
|
|
|
| 208 |
with respect to one another within each thread of execution. These
|
| 209 |
threads of execution are either the invoking thread of execution or
|
| 210 |
threads of execution implicitly created by the library; the latter will
|
| 211 |
provide weakly parallel forward progress guarantees.
|
| 212 |
|
| 213 |
+
[*Note 7*: This means that multiple function object invocations can be
|
| 214 |
interleaved on a single thread of execution, which overrides the usual
|
| 215 |
guarantee from [[intro.execution]] that function executions do not
|
| 216 |
overlap with one another. — *end note*]
|
| 217 |
|
| 218 |
The behavior of a program is undefined if it invokes a
|
| 219 |
vectorization-unsafe standard library function from user code called
|
| 220 |
+
from an `execution::parallel_unsequenced_policy` algorithm.
|
| 221 |
|
| 222 |
[*Note 8*: Because `execution::parallel_unsequenced_policy` allows the
|
| 223 |
execution of element access functions to be interleaved on a single
|
| 224 |
thread of execution, blocking synchronization, including the use of
|
| 225 |
mutexes, risks deadlock. — *end note*]
|