<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 3143: monotonic_buffer_resource growth policy is unclear</title>
<meta property="og:title" content="Issue 3143: monotonic_buffer_resource growth policy is unclear">
<meta property="og:description" content="C++ library issue. Status: C++23">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue3143.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#C++23">C++23</a> status.</em></p>
<h3 id="3143"><a href="lwg-defects.html#3143">3143</a>. <code>monotonic_buffer_resource</code> growth policy is unclear</h3>
<p><b>Section:</b> 20.5.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a> <b>Status:</b> <a href="lwg-active.html#C++23">C++23</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2018-07-20 <b>Last modified:</b> 2023-11-22</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++23">C++23</a> status.</p>
<p><b>Discussion:</b></p>
<p>
During the discussion of LWG <a href="lwg-defects.html#3120" title="Unclear behavior of monotonic_buffer_resource::release() (Status: C++23)">3120</a><sup><a href="https://cplusplus.github.io/LWG/issue3120" title="Latest snapshot">(i)</a></sup> it was pointed out that the current
wording in 20.5.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a> is contradictory. The introductory text for 
the class says "Each additional buffer is larger than the previous one, following 
a geometric progression" but the spec for <code>do_allocate</code> doesn't agree.
<p/>
Firstly, it's impossible for the implementation to ensure a single geometric progression, 
because the size of the next buffer can be arbitrarily large. If the caller asks for an 
allocation that is <code>N</code> times bigger than the previous buffer, the next buffer will be at
least <code>N</code> times larger than the previous one. If <code>N</code> is larger than the
implementation-defined growth factor it's not a geometric progression.
<p/>
Secondly, it's not even clear that each additional buffer will be larger than the previous one. 
Given a <code>monotonic_buffer_resource</code> object with little remaining space in <code>current_buffer</code>, 
a request to allocate <code>10*next_buffer_size</code> will:
<p/>
"set <code>current_buffer</code> to <code>upstream_rsrc-&gt;allocate(n, m)</code>, where <code>n</code> is not
less than <code>max(bytes, next_buffer_size)</code> and <code>m</code> is not less than <code>alignment</code>, 
and increase <code>next_buffer_size</code> by an implementation-defined growth factor (which need not 
be integral), then allocate the return block from the newly-allocated <code>current_buffer</code>."
<p/>
The effects are to allocate a new buffer of at least <code>max(10*next_buffer_size, next_buffer_size)</code> 
bytes, and then do <code>next_buffer_size *= growth_factor</code>. If <code>growth_factor &lt; 10</code> then 
the next allocated buffer might be smaller than the last one. This means that although 
<code>next_buffer_size</code> itself follows a geometric progression, the actual size of any single 
allocated buffer can be much larger than <code>next_buffer_size</code>. A graph of the allocated sizes looks 
like a geometric progression with spikes where an allocation size is larger than <code>next_buffer_size</code>.
<p/>
If the intention is to set <code>next_buffer_size = max(n, next_buffer_size * growth_factor)</code> so 
that every allocation from upstream is larger than the previous one, then we need a change to the 
<i>Effects:</i> to actually say that. Rather than a geometric progression with anomalous spikes,
this would produce a number of different geometric progressions with discontinuous jumps between them.
<p/>
If the spiky interpretation is right then we need to weaken the "Each additional buffer is larger" 
statement. Either way, we need to add a caveat to the "following a geometric progression" text 
because that isn't true for the spiky interpretation or the jumpy interpretation.
<p/>
Thirdly, the <i>Effects:</i> says that the size of the allocated block, <code>n</code>, is not less than 
<code>max(bytes, next_buffer_size)</code>. This seems to allow an implementation to choose to do 
<code>n = ceil2(max(bytes, next_buffer_size))</code> if it wishes (maybe because allocating sizes that 
are a power of 2 simplifies the <code>monotonic_buffer_resource</code> implementation, or allows reducing 
the bookkeeping overhead). This still results in an approximate geometric progression (under either 
the spiky or jumpy interpretation) but the graph has steps rather than being a smooth curve (but 
always above the curve). This is another way that "Each additional buffer is larger than the previous 
one" is not guaranteed. Even if <code>max(bytes, next_buffer_size)</code> is greater on every call, for a
growth factor between <code>1.0</code> and <code>2.0</code> the result of <code>ceil2</code> might be the same 
for two successive buffers. I see no reason to forbid this, but Pablo suggested it's not allowed 
because it doesn't result in exponential growth (which I disagree with). If this is supposed to be
forbidden, the wording needs to be fixed to forbid it.
</p>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 2</p>

<p><i>[2020-02-13, Prague]</i></p>

<p>
LWG looked at the issue and a suggestion was presented to eliminate most of 20.5.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a>
to solve the problem the current requirements impose.
</p>

<p><i>[2020-02-16; Prague]</i></p>

<p>Reviewed revised wording and moved to Ready for Varna.</p>

<p><i>[2020-11-09 Approved In November virtual meeting. Status changed: Ready &rarr; WP.]</i></p>



<p id="res-3143"><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4849">N4849</a>.</p>

<ol>
<li><p>Modify 20.5.6 <a href="https://wg21.link/mem.res.monotonic.buffer">[mem.res.monotonic.buffer]</a>, as indicated:</p>

<blockquote>
<p>
-1- A <code>monotonic_buffer_resource</code> is a special-purpose memory resource intended for very fast memory allocations
in situations where memory is used to build up a few objects and then is released all at once when the
memory resource object is destroyed. <del>It has the following qualities:</del>
</p>
<ol style="list-style-type: none"> 
<li><p><del>(1.1) &mdash; A call to <code>deallocate</code> has no effect, thus the amount of memory consumed increases 
monotonically until the resource is destroyed.</del></p></li>
<li><p><del>(1.2) &mdash; The program can supply an initial buffer, which the allocator uses to satisfy memory requests.</del></p></li>
<li><p><del>(1.3) &mdash; When the initial buffer (if any) is exhausted, it obtains additional buffers from an upstream 
memory resource supplied at construction. Each additional buffer is larger than the previous one, following a
geometric progression.</del></p></li>
<li><p><del>(1.4) &mdash; It is intended for access from one thread of control at a time. Specifically, calls to <code>allocate</code> and
<code>deallocate</code> do not synchronize with one another.</del></p></li>
<li><p><del>(1.5) &mdash; It frees the allocated memory on destruction, even if <code>deallocate</code> has not been called 
for some of the allocated blocks.</del></p></li>
</ol>
</blockquote>
</li>

</ol>





</body>
</html>
