memory_order_seq_cst防护栅什么时候有用? [英] When is a memory_order_seq_cst fence useful?

问题描述

C ++支持的 atomic 线程防护，即使用功能 atomic_thread_fence 的篱笆保证使用 std :: atomic<> 操作的线程的属性.代码>.它需要一个内存顺序参数来调整围栏的强度".

C++ supported atomic thread fences, that is fences guaranteeing properties for thread that use std::atomic<> operations, with the function atomic_thread_fence. It takes a memory order parameter to adjust the "strength" of the fence.

我了解到，并非所有原子操作都以强"顺序完成时，围栏很有用:

I understand that fences are useful when not all atomic operations are done with a "strong" order:

• 当线程中的并非所有原子读取(1)是获取操作时，您可能会发现使用获取栅栏；
• 当线程中的并非所有原子修改(1)是释放操作时，您可能会发现释放栅栏的用途.

• when not all atomic reads (1) in a thread are acquire operations, you may find a use for an acquire fence;
• when not all atomic modifications (1) in a thread are release operations, you may find a use for a release fence.

(1)包含RMW操作

因此，所有这些(获取，释放和acq_rel防护)的用处都是显而易见的:它们允许使用原子操作(分别比acq/rel弱)的线程正确同步.

So the usefulness of all these (acquire, release and acq_rel fences) is obvious: they allow threads that use atomic operations weaker than acq/rel (respectively) to synchronize properly.

但是我不知道在哪里特别需要 memory_order_seq_cst 作为围栏:

But I don't understand where memory_order_seq_cst could be specifically needed as a fence:

• 使用弱于 memory_order_seq_cst 原子操作和 memory_order_seq_cst 栅栏的含义是什么?

• What's the implication of using weaker than memory_order_seq_cst atomic operations and a memory_order_seq_cst fence?

memory_order_seq_cst 栅栏将特别保证(就原子操作的可能排序而言)，而 memory_order_acq_rel 无法保证?p>

What would specifically be guaranteed (in term of possible ordering of atomic operations) by a memory_order_seq_cst fence that wouldn't be guaranteed by memory_order_acq_rel?

推荐答案

不，seq-cst-fence不仅是发行版，也包括acquired-fence，还提供了一些其他属性(请参见

No, a seq-cst-fence is not only both a release and an acquire-fence, but also provides some additional properties (see Working Draft, Standard for Programming Language C++, 32.4.4-32.4.8). A seq-cst fence is also part of the single total order of all sequentially consistent operations, enforcing the following observations:

• 对于读取原子对象 M 值的原子操作 B ，如果存在 memory_order_seq_cst 栅栏 X 在 B 之前排序，然后 B 观察在 X之前对 M 的最后 memory_order_seq_cst 修改的总顺序为 S 或 M 的后续修改顺序.
• 对于原子对象 M 上的原子操作 A 和 B ，其中 A 修改 M和 B 取其值，如果存在 memory_order_seq_cst 栅栏 X ，从而对 A 进行了排序在 S 中的 X 和 B 跟随 X 之前，然后 B 观察到其中一种效果 A 的版本或 M 的更高版本(按其修改顺序).
• 对于原子对象 M 上的原子操作 A 和 B ，其中 A 修改 M和 B 取其值，如果存在 X 和 Y 围栏> A 在 X 之前排序， Y 在 B 之前排序，并且 X 在之前 S 中的> Y ，然后 B 观察 A 的作用或后来对 M 按其修改顺序.

• For an atomic operation B that reads the value of an atomic object M, if there is a memory_order_seq_cst fence X sequenced before B, then B observes either the last memory_order_seq_cst modification of M preceding X in the total order S or a later modification of M in its modification order.
• For atomic operations A and B on an atomic object M, where A modifies M and B takes its value, if there is a memory_order_seq_cst fence X such that A is sequenced before X and B follows X in S, then B observes either the effects of A or a later modification of M in its modification order.
• For atomic operations A and B on an atomic object M, where A modifies M and B takes its value, if there are memory_order_seq_cst fences X and Y such that A is sequenced before X, Y is sequenced before B, and X precedes Y in S, then B observes either the effects of A or a later modification of M in its modification order.

例如，我在危险指示器实现中使用了seq-cst栅栏: https://github.com/mpoeter/xenium/blob/master/xenium/reclamation/impl/hazard_pointer.hpp
在存储了危险指针之后，但在重新读取指向该对象的指针之前，获得对某些对象的安全引用的线程使用seq-cst围栏.试图回收某些对象的线程在从所有线程收集活动危害指针之前使用seq-cst防护.根据上述规则，这可以确保尝试回收该对象的线程看到其他某个线程对该对象具有HP(即，使用了该对象)，或者确保尝试获取对该对象的安全引用的线程重载返回一个不同的指针，指示该线程该对象已被删除，并且必须执行重试.

For example, I am using seq-cst fences in my hazard pointer implementation: https://github.com/mpoeter/xenium/blob/master/xenium/reclamation/impl/hazard_pointer.hpp
The thread acquiring a safe reference to some object uses seq-cst fence after storing the hazard pointer, but before re-reading the pointer to the object. The thread trying to reclaim some objects uses a seq-cst fence before gathering the active hazard pointers from all threads. Based on the rules above this ensures that either the thread trying to reclaim the object sees that some other thread has a HP for this object (i.e., the object is used), or the reload of thread trying to acquire the safe reference to the object returns a different pointer, indicating to that thread that the object has been removed and it has to perform a retry.

这篇关于memory_order_seq_cst防护栅什么时候有用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！