This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++17 status.

### 2718. Parallelism bug in [algorithms.parallel.exec] p2

Section: 27.3.3 [algorithms.parallel.exec] Status: C++17 Submitter: Jared Hoberock Opened: 2016-05-25 Last modified: 2017-07-30

Priority: Not Prioritized

View all other issues in [algorithms.parallel.exec].

View all issues with C++17 status.

Discussion:

The paragraph describing the effect of composing `sequential_execution_policy` with parallel algorithms says:

> The invocations of element access functions in parallel algorithms invoked with an execution policy object of type `sequential_execution_policy` are indeterminately sequenced (1.9) in the calling thread.

The intended behavior of `sequential_execution_policy` is to match the classic-style algorithm semantics, cf. 27.3.5 [algorithms.parallel.overloads] p2:

> Unless otherwise specified, the semantics of `ExecutionPolicy` algorithm overloads are identical to their overloads without.

Because many classic-style algorithms execute element access functions in a specified sequence, 27.3.3 [algorithms.parallel.exec] p2 introduces unintentionally different semantics between classic-style algorithms and parallel algorithms invoked with `sequential_execution_policy`.

The unintentional change to 27.3.3 [algorithms.parallel.exec] p2 was introduced in the revision from P0024R1 to P0024R0 when the wording was changed from

> The invocations of element access functions in parallel algorithms invoked with an execution policy object of type `sequential_execution_policy` execute in sequential order in the calling thread.

to

> The invocations of element access functions in parallel algorithms invoked with an execution policy object of type `sequential_execution_policy` are indeterminately sequenced (1.9) in the calling thread.

Suggested resolution:

To restore the originally intended behavior of `sequential_execution_policy`, Jens Maurer suggests replacing 27.3.3 [algorithms.parallel.exec] p2 with:

> The invocations of element access functions in parallel algorithms invoked with an execution policy object of type `sequential_execution_policy` all occur in the calling thread. [Note: The invocations are not interleaved; see 6.9.1 [intro.execution] — end note]

[2016-06 Oulu]

Could be P0 after SG1 gives OK

Tuesday, Oulu: Hans Ok'd this

Friday: status to Immediate

Proposed resolution:

This wording is relative to N4582.

1. Change 27.3.3 [algorithms.parallel.exec] as indicated:

   > The invocations of element access functions in parallel algorithms invoked with an execution policy object of type `sequential_execution_policy` all occur are indeterminately sequenced (1.9) in the calling thread. [Note: The invocations are not interleaved; see 6.9.1 [intro.execution] — end note]