<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2917: Parallel algorithms cannot easily work with InputIterators</title>
<meta property="og:title" content="Issue 2917: Parallel algorithms cannot easily work with InputIterators">
<meta property="og:description" content="C++ library issue. Status: Resolved">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2917.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#Resolved">Resolved</a> status.</em></p>
<h3 id="2917"><a href="lwg-defects.html#2917">2917</a>. Parallel algorithms cannot easily work with <code>InputIterator</code>s</h3>
<p><b>Section:</b> 26 <a href="https://wg21.link/algorithms">[algorithms]</a>, 26.10 <a href="https://wg21.link/numeric.ops">[numeric.ops]</a> <b>Status:</b> <a href="lwg-active.html#Resolved">Resolved</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2017-02-03 <b>Last modified:</b> 2020-09-06</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#algorithms">active issues</a> in [algorithms].</p>
<p><b>View all other</b> <a href="lwg-index.html#algorithms">issues</a> in [algorithms].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Resolved">Resolved</a> status.</p>
<p><b>Discussion:</b></p>
<b>Addresses US 156</b>

<p>Parallel algorithms cannot easily work with <code>InputIterator</code>s, as any attempt to partition the work is going to 
invalidate iterators used by other sub-tasks. While this may work for the sequential execution policy, the goal of that 
policy is to transparently switch between serial and parallel execution of code without changing semantics, so there 
should not be a special case extension for this policy. There is a corresponding concern for writing through 
<code>OutputIterator</code>s. Note that the input iterator problem could be mitigated, to some extent, by serially copying/moving 
data out of the input range and into temporary storage with a more favourable iterator category, and then the work of the 
algorithm can be parallelized. If this is the design intent, a note to confirm that in the standard would avoid future 
issues filed in this area. However, the requirement of an algorithm that must copy/move values into intermediate storage 
may not be the same as those acting immediately on a dereferenced input iterator, and further issues would be likely. 
It is not clear that anything can be done to improve the serial nature of writing to a simple output iterator though.</p>
<p>Proposed change: All algorithms in the <code>&lt;algorithm&gt;</code> and <code>&lt;numeric&gt;</code> headers that take an 
execution policy and an <code>InputIterator</code> type should update that iterator to a <code>ForwardIterator</code>, and similarly 
all such overloads taking an <code>OutputIterator</code> should update that iterator to a <code>ForwardIterator</code>.</p>
<p>(Conversely, if the design intent is confirmed to support input and output iterators, add a note to state that clearly and avoid confusion and more issues by future generations of library implementers.)</p>

<p><i>[2017-02-13, Alisdair comments]</i></p>

<p>
The pre-Kona mailing has two competing papers that provide wording to address #2917,
sequential constraints on parallel algorithms. They should probably be cross-refrenced
by the issue:
</p>
<ol>
<li><p><a href="https://wg21.link/p0467r1">P0467R1</a>: Iterator Concerns for Parallel Algorithms</p></li>
<li><p><a href="https://wg21.link/p0574r0">P0574R0</a>: Algorithm Complexity Constraints and Parallel Overloads</p></li>
</ol>

<p><i>[2017-03-12, post-Kona]</i></p>

<p>Resolved by P0467R2.</p>


<p id="res-2917"><b>Proposed resolution:</b></p>
<p>
</p>










</body>
</html>
