blocks|key|173894|text|数据依赖项排序是由N2492引入的，其基本原理如下：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|173895|173896|在两个重要的用例中，当前的工作草案(N2461)不支持在某些现有硬件上尽可能接近的可伸缩性。|blockquote|173897|173898|173899|173900|对极少写入的并发数据结构的读访问权限|unordered-list-item|173901|173902|很少编写的并发数据结构在操作系统内核和服务器风格的应用程序中都很常见。示例包括表示外部状态的数据结构(例如路由表)、软件配置(当前加载的模块)、硬件配置(当前使用的存储设备)和安全策略(访问控制权限、防火墙规则)。读写比远远超过十亿比1是相当常见的。|173903|指针中介发布的|173904|publish-subscribe语义|173905|173906|线程之间的许多通信都是指针中介的，生产者发布一个指针，消费者可以通过该指针访问信息。在没有完全获取语义的情况下，访问数据是可能的。|173907|在这种情况下，在支持线程间数据依赖关系排序的机器上，使用线程间数据依赖关系排序已经导致了数量级的加速和类似的可伸缩性改进。这样的加速是可能的，因为这样的机器可以避免昂贵的锁获取、原子指令或否则需要的内存栅栏。|style|BOLD|173908|强调我的|173909|令人兴奋的用例是来自Linux内核的rcu_dereference()。|CODE|173910|entityMap|0|LINK|mutability|MUTABLE|url|http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html^0|9|5|0|0|0|0|0|0|0|0|0|0|0|0|0|0|Q|O|0|0|I|H|0^^$0|@$1|2|3|4|5|6|7|1E|8|@]|9|@$A|1F|B|1G|1|1H]]|C|$]]|$1|D|3|-4|5|6|7|1I|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|1J|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|1K|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1N|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1O|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1P|8|@]|9|@]|C|$]]|$1|Q|3|R|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|S|3|T|5|M|7|1R|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1S|8|@]|9|@]|C|$]]|$1|V|3|W|5|6|7|1T|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|1U|8|@$A|1V|B|1W|Z|10]]|9|@]|C|$]]|$1|11|3|12|5|6|7|1X|8|@]|9|@]|C|$]]|$1|13|3|14|5|6|7|1Y|8|@$A|1Z|B|20|Z|15]]|9|@]|C|$]]|$1|16|3|-4|5|6|7|21|8|@]|9|@]|C|$]]]|17|$18|$5|19|1A|1B|C|$1C|1D]]]]

Data dependency ordering was introduced by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2492.html" rel="noreferrer">N2492</a> with the following rationale:
<blockquote>
There are two significant use cases where the current working draft (N2461) does not support scalability near that possible on some existing hardware.
<ul>
<li>read access to rarely written concurrent data structures</li>
</ul>
Rarely written concurrent data structures are quite common, both in operating-system kernels and in server-style applications. Examples include data structures representing outside state (such as routing tables), software configuration (modules currently loaded), hardware configuration (storage device currently in use), and security policies (access control permissions, firewall rules). Read-to-write ratios well in excess of a billion to one are quite common.
<ul>
<li>publish-subscribe semantics for pointer-mediated publication</li>
</ul>
Much communication between threads is pointer-mediated, in which the producer publishes a pointer through which the consumer can access information. Access to that data is possible without full acquire semantics.
In such cases, use of inter-thread data-dependency ordering has resulted in order-of-magnitude speedups and similar improvements in scalability on machines that support inter-thread data-dependency ordering. Such speedups are possible because such machines can avoid the expensive lock acquisitions, atomic instructions, or memory fences that are otherwise required.
</blockquote>
emphasis mine
the motivating use case presented there is <code>rcu_dereference()</code> from the Linux kernel

blocks|key|172258|text|load-+the与load-acquire非常相似，只是它只对依赖于load-the的表达式求值引入了发生之前的关系。使用kill_dependency包装表达式将产生一个不再携带来自负载消耗的依赖项的值。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|172259|关键用例是编写器按顺序构造数据结构，然后(使用release或acq_rel原子)将共享指针摆动到新结构。读取器使用load-use来读取指针，并解除对它的引用以获得数据结构。取消引用创建了一个数据依赖项，因此确保读取器可以看到初始化的数据。|172260|std::atomic<int+*>+foo+{nullptr};
std::atomic<int>+bar;

void+thread1()
{
++++bar+=+7;
++++int+*+x+=+new+int+{51};
++++foo.store(x,+std::memory_order_release);
}

void+thread2()
{
++++int+*y+=+foo.load(std::memory_order_consume)
++++if+(y)
++++{
++++++++assert(*y+==+51);+//succeeds
++++++++//+assert(bar+==+7);+//undefined+behavior+-+could+race+with+the+store+to+bar+
++++++++//+assert(kill_dependency(*y)+%2B+bar+==+58)+//+undefined+behavior+(same+reason)
++++++++assert(*y+%2B+bar+==+58);+//+succeeds+-+evaluation+of+bar+pulled+into+the+dependency+
++++}
}|code-block|syntax|javascript|172261|提供负载消耗有两个原因。主要原因是ARM和电源负载肯定会消耗，但需要额外的围栏才能将它们转换为获取。(在x86上，所有加载都是获取的，因此在朴素编译下，使用不会提供直接的性能优势。)第二个原因是编译器可以在没有数据依赖的情况下将操作移到消费之前，而这对于获取是做不到的。(启用这样的优化是将所有这些内存排序构建到语言中的主要原因。)|172262|通过使用kill_dependency包装一个值，可以计算依赖于要在加载-消耗之前移动到的值的表达式。例如，当值是先前读取的数组的索引时，这很有用。|172263|请注意，使用use会导致不再是可传递的发生之前关系(尽管它仍然保证是非循环的)。例如，对bar的存储发生在对foo的存储之前，这发生在对y的取消引用之前，这发生在读取bar+(在注释掉的assert中)之前，但是对bar的存储不会在读取bar之前发生。这导致了一个相当复杂的发生之前的定义，但你可以想象它是如何工作的(从sequenced+leads开始，然后通过任意数量的release-consume-dataDependency或release-acquire-sequencedBefore+)|172264|entityMap^0|1Q|F|0|N|7|V|7|0|0|0|4|F|0|18|3|1W|1|2B|3|2Z|3|3A|3|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1I|8|@]|D|@]|E|$]]]|T|$]]

Load-consume is much like load-acquire, except that it induces happens-before relationships only to expression evaluations that are data-dependent on the load-consume. Wrapping an expression with <code>kill_dependency</code> results in a value that no longer carries a dependency from the load-consume. 

The key use case is for the writer to construct a data structure sequentially, then swing a shared pointer to the new structure (using a <code>release</code> or <code>acq_rel</code> atomic). The reader uses load-consume to read the pointer, and dereferences it to get to the data structure. The dereference creates a data dependency, so the reader is guaranteed to see the initialized data.

<pre><code>std::atomic&lt;int *&gt; foo {nullptr};
std::atomic&lt;int&gt; bar;

void thread1()
{
 bar = 7;
 int * x = new int {51};
 foo.store(x, std::memory_order_release);
}

void thread2()
{
 int *y = foo.load(std::memory_order_consume)
 if (y)
 {
 assert(*y == 51); //succeeds
 // assert(bar == 7); //undefined behavior - could race with the store to bar 
 // assert(kill_dependency(*y) + bar == 58) // undefined behavior (same reason)
 assert(*y + bar == 58); // succeeds - evaluation of bar pulled into the dependency 
 }
}
</code></pre>

There are two reasons for providing load-consume. The primary reason is that ARM and Power loads are guaranteed to consume, but require additional fencing to turn them into acquires. (On x86, all loads are acquires, so consume provides no direct performance advantage under naive compilation.)
The secondary reason is that the compiler can move later operations without data dependence up to before the consume, which it can't do for an acquire. (Enabling such optimizations is the big reason for building all of this memory ordering into the language.) 

Wrapping a value with <code>kill_dependency</code> allows computation of an expression that depends on the value to be moved to before the load-consume. This is useful e.g. when the value is an index into an array that was previously read.

Note that the use of consume results in a happens-before relation that is no longer transitive (though it is still guaranteed to be acyclic). For example, the store to <code>bar</code> happens before the store to foo, which happens before the dereference of <code>y</code>, which happens before the read of <code>bar</code> (in the commented-out assert), but the store to <code>bar</code> doesn't happen before the read of <code>bar</code>. This leads to a rather more complicated definition of happens-before, but you can imagine how it works (start with sequenced-before, then propagate through any number of release-consume-dataDependency or release-acquire-sequencedBefore links)

blocks|key|170160|text|Jeff+Preshing有一篇很棒的博客文章回答了这个问题。我自己不能添加任何东西，但我认为任何想知道消费与获取的人都应该阅读他的帖子：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|170161|http://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/|offset|length|170162|他展示了一个特定的C%2B%2B示例，其中包含三种不同架构上的相应基准汇编代码。与memory_order_acquire相比，memory_order_consume可能会在PowerPC上提供3倍的加速，在ARM上提供1.6倍的加速，而在x86上的加速可以忽略不计，因为x86具有很强的一致性。问题是，在写这篇文章的时候，只有GCC真正对待消费语义与获取语义有任何不同，而且可能是因为一个bug。尽管如此，它表明，如果编译器编写者能够找出如何利用它，那么加速是可用的。|style|CODE|170163|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|22|0|0|11|K|1O|K|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@$D|S|E|T|1|U]]|A|$]]|$1|F|3|G|5|6|7|V|8|@$D|W|E|X|H|I]|$D|Y|E|Z|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|C]]]]

Jeff Preshing has a great blog post answering this question. I can't add anything myself, but think anyone wondering about consume vs. acquire should read his post:

<a href="http://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/" rel="nofollow noreferrer">http://preshing.com/20140709/the-purpose-of-memory_order_consume-in-cpp11/</a>

He shows a specific C++ example with corresponding benchmarked assembly code across three different architectures. Compared to <code>memory_order_acquire</code>, <code>memory_order_consume</code> potentially offers a 3x speedup on PowerPC, 1.6x speedup on ARM, and negligible speedup on x86 which has strong consistency anyway. The catch is that as of when he wrote it, only GCC actually treated consume semantics any differently from acquire, and probably because of a bug. Nonetheless, it demonstrates that a speedup is available if the compiler writers can figure out how to take advantage of it.

The C++11 standard defines a memory model (1.7, 1.10) which contains memory orderings, which are, roughly, "sequentially-consistent", "acquire", "consume", "release", and "relaxed". Equally roughly, a program is correct only if it is race-free, which happens if all actions can be put in some order in which one action happens-before another one. The way that an action X happens-before an action Y is that either X is sequenced before Y (within one thread), or X inter-thread-happens-before Y. The latter condition is given, among others, when

<ul>
<li>X synchronizes with Y, or</li>
<li>X is dependency-ordered before Y.</li>
</ul>

Synchronizing-with happens when X is an atomic store with "release" ordering on some atomic variable, and Y is an atomic load with "acquire" ordering on the same variable. Being dependency-ordered-before happens for the analogous situation where Y is load with "consume" ordering (and a suitable memory access). The notion of synchronizes-with extends the happens-before relationship transitively across actions being sequenced-before one another within a thread, but being dependency-ordered-before is extended transitively only through a strict subset of sequenced-before called carries-dependency, which follows a largish set of rules, and notably can be interrupted with <code>std::kill_dependency</code>.

Now then, what is the purpose of the notion of "dependency ordering"? What advantage does it provide over the simpler sequenced-before / synchronizes-with ordering? Since the rules for it are stricter, I assume that can be implemented more efficiently.

Can you give an example of a program where switching from release/acquire to release/consume is both correct and provides a non-trivial advantage? And when would <code>std::kill_dependency</code> provide an improvement? High-level arguments would be nice, but bonus points for hardware-specific differences.

How do "acquire" and "consume" memory orders differ, and when is "consume" preferable?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

C++11标准定义了一个内存模型(1.7，1.10)，其中包含内存排序，大致为“顺序一致”、“获取”、“消耗”、“释放”和“松弛”。同样粗略地说，一个程序只有在没有竞争的情况下才是正确的，这发生在所有动作都可以按某种顺序排列，其中一个动作发生在另一个动作之前。动作X在动作Y之前发生的方式是X在Y之前排序(在一个线程内)...

问“获取”和“消耗”内存顺序有何不同，什么时候“消耗”更可取？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问“获取”和“消耗”内存顺序有何不同，什么时候“消耗”更可取？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问“获取”和“消耗”内存顺序有何不同，什么时候“消耗”更可取？
EN