<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<title>P0371R0: Temporarily deprecate memory_order_consume</title>
</head>
<body>
<table>
	<tr>
                <th>Doc. No.:</th>
                <td>WG21/P0371R0</td>
        </tr>
        <tr>
                <th>Date:</th>
                <td>2016-05-26</td>
        </tr>
        <tr>
                <th>Author:</th>
                <td>Hans-J. Boehm</td>
        </tr>
        <tr>
                <th>Email:</th>
                <td><a href="mailto:hboehm@google.com">hboehm@google.com</a></td>
        </tr>
        <tr>
                <th>Target:</th>
                <td>SG1, then probably CWG</td>
        </tr>
</table>
<h1>P0371R0: Temporarily deprecate memory_order_consume</h1>
<p>
It is widely accepted that the current definition of
<code>memory_order_consume</code> in the standard is not useful.
All current compilers essentially map it to
<code>memory_order_acquire</code>.
The difficulties appear to stem both from the high implementation complexity,
from the fact that the current definition uses a fairly general definition
of "dependency", thus requiring frequent and inconvenient use of the
<code>kill_dependency</code> call, and from the
frequent need for <code>[[carries_dependency]]</code> annotations.
Details can be found in e.g.
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0098r0.pdf">
P0098R0</a>.
<p>
Nonetheless, it is also widely accepted that <code>memory_order_consume</code>
has frequent and important use cases in many large code bases.  For example,
the Linux kernel makes extensive use of RCU, which relies on this facility
for weakly ordered architectures like ARM and Power.
Some core Android code similarly relies on dependency-based ordering.
Currently there is no way to express this code in a way that is both performant
and standard-conforming.
Thus SG1 continues to discuss improved, more usable, versions.  See
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0190r1.pdf">
P0190R1</a> or successors. It is likely that any such revision will not be
fully backwards-compatible with the old one, but will better support
common use cases.
<p>
The current expectation is that the replacement facility will rely on
core memory model and atomics definitions very similar to what's currently
there.  Since <code>memory_order_consume</code> does have a profound impact
on the memory model, removing this text would allow drastic simplification,
but conversely would make it very difficult to add anything along the lines of
<code>memory_order_consume</code> back in later, especially if the standard
evolves in the meantime, as expected.  Thus we are not proposing to
remove the current wording.

<h2>Proposed wording</h2>
<p>
It is not feasible to move all affected text to Annex D, but there
seem be precedents (e.g. D.2) for defining features in the body of the
standard and declaring them deprecated here.  It is also unsafe to
simply remove <code>memory_order_consume</code> from the enumeration
type to which it belongs,
since this would change the value of the other enumeration constants.
And we know that there is important code that relies on those, even
aside from ABI issues.  Thus we propose the following relatively
small changes:
<p>
Add a new paragraph to Annex D:
<blockquote>
<p>
<ins>
<b>D.? memory_order_consume&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[depr.consume]</b></ins>
<p>
<ins>The use of <code>memory_order_consume</code> is deprecated.
[Note:
<code>Memory_order_acquire</code> may be used instead.
<code>Memory_order_consume</code> replacements with somewhat different meaning are
under consideration for a future version of the standard.
--end note]</ins>
</blockquote>
<p>
It is unclear what to do with the <code>kill_dependency</code> function and
the <code>carries_dependency</code> attribute.  My sense is that we will want to
approximately preserve <code>kill_dependency</code>, but that
<code>carries_dependency</code> will probably need to be specified significantly
differently. <code>Carries_dependency</code> is also better isolated from
everything else.  Thus I suggest moving only <code>carries_dependency</code>.
<p>
Move section 7.6.4 [dcl.attr.depend] to Annex D.  Add an introductory sentence:
<blockquote>
<p>
<ins> One additional <i>attribute-token</i> (7.6.1 [dcl.attr.grammar]) is specified.</ins>
</blockquote>
</body>
</html>


