|Target:||LWG, maybe CWG|
It is widely accepted that the current definition of
memory_order_consume in the standard is not useful.
All current compilers essentially map it to
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
kill_dependency call, and from the
frequent need for
Details can be found in e.g.
Nonetheless, it is also widely accepted that
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
Thus SG1 continues to discuss improved, more usable, versions. See
P0190R1 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.
The current expectation is that the replacement facility will rely on
core memory model and atomics definitions very similar to what's currently
memory_order_consume 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
memory_order_consume back in later, especially if the standard
evolves in the meantime, as expected. Thus we are not proposing to
remove the current wording.
SG1 did not want to officially deprecate
as was proposed in Revision 0.
But we did want to inform users of the problem. The following reflects
Change 29.3p1.3 [atomics.order] as follows:
-- memory_order_consume: a load operation performs a consume operation on the affected memory location.