[[carries_dependency]]的含义和实现方法

如何解决[[carries_dependency]]的含义和实现方法

我在这篇SO帖子中读到有关[[carries_dependency]]的信息。

但是我不明白的是接受答案中的以下句子：

”特别是，如果传入用memory_order_consume读取的值 到一个函数，然后没有[[carries_dependency]]，然后是编译器 可能必须发出内存防护指令以确保 保留适当的内存排序语义。如果参数是 用[[carries_dependency]]注释，然后编译器可以假定 函数主体将正确地携带依赖关系，并且这 栅栏可能不再必要。

类似地，如果函数返回一个加载有 memory_order_consume，或从这样的值派生，则没有 [[carries_dependency]]可能需要编译器插入篱笆 指令以确保适当的内存顺序 语义得到维护。使用[[carries_dependency]]批注，此 围墙可能不再是必需的，因为呼叫者现在负责 维护依赖关系树。”

让我们逐步进行：

“如果将使用memory_order_consume读取的值传递给函数， 然后如果没有[[carries_dependency]]，则编译器可能不得不 发出内存围栏指令以确保适当的 内存排序语义得以保留。”

因此，对于释放消费型内存模型中的原子变量，当将原子变量作为参数传递给函数时，编译器将引入fence硬件指令，以便始终具有提供给原子变量的最新和更新值。功能。

下一步-

“如果参数用[[carries_dependency]]注释，则 编译器可以假定函数主体将正确携带 依赖性，并且可能不再需要此防护栅。”

这让我感到困惑-原子变量值已经被消耗了，那么函数的依赖关系又是什么呢？

类似地-

”，如果函数返回装载有memory_order_consume的值，或者 从这样的值派生，然后没有[[carries_dependency]] 可能要求编译器插入fence指令以确保 维护适当的内存排序语义。随着 [[carries_dependency]]批注，此围栏可能不再是 必要，因为呼叫者现在负责维护 依赖树。”

从该示例中，尚不清楚它要说明的关于携带依赖项的要点是什么？

解决方法

仅供参考，memory_order_consume（和[[carries_dependency]]）实际上已被弃用，因为对于编译器而言，很难像C ++ 11那样有效，正确地实现规则。 （和/或因为[[carries_dependency]]和/或kill_dependency最终将在整个地方都需要。）请参见P0371R1: Temporarily discourage memory_order_consume。

当前的编译器只是将mo_consume视为mo_acquire（因此，在需要一个的ISA上，在消耗负载之后设置一个障碍）。如果要实现无障碍数据依赖排序，则必须使用mo_relaxed欺骗编译器，并仔细编码，以免使编译器可能在没有实际依赖的情况下创建asm。 （例如Linux RCU）。有关更多详细信息和链接以及mo_consume旨在公开的asm功能，请参见C++11: the difference between memory_order_relaxed and memory_order_consume。

也Memory order consume usage in C11。
了解依赖顺序的概念（在asm中）对于理解此C ++功能的设计基本上至关重要。

当将[an]原子变量作为参数传递给函数时，编译器将引入围栏硬件指令...

首先，您不会将“原子变量”传递给函数；那甚至意味着什么？如果您要传递指向原子对象的指针或引用，则该函数将对其进行自身的加载，并且该函数的源代码将使用或不使用memory_order_consume。

相关的事情是使用mo_consume从原子变量传递值 loaded 。像这样：

    int tmp = shared_var.load(std::memory_order_consume);
    func(tmp);

func可以使用该arg作为atomic<int>数组的索引来进行mo_relaxed加载。为了使加载在shared_var.load之后依序进行排序，即使没有内存屏障，func的代码源也必须确保该加载对arg有asm数据依赖关系，即使C ++代码也是如此做类似tmp -= tmp;的事情，编译器通常只会将它们与tmp = 0;一样对待（杀死先前的值）。

但是[[carries_dependency]]将使编译器在实现类似array[idx+tmp]的过程中仍然引用具有数据依赖性的零值。

原子变量值已经被消耗了，那么函数的依赖关系是什么？

“已消耗”是无效的概念。 consume而非acquire的全部要点在于，以后的加载正确排序，因为它们对mo_consume加载结果具有 data 依赖性，从而避免了障碍。如果要在原始加载之后进行排序，则以后的每个加载都需要这样的依赖关系。您无法说一个值“已经消耗”。

如果由于对一个函数缺少carry_dependency而最终插入了障碍来促进消费获取，那么以后的函数就不需要另一个障碍，因为您可以说该值是“已经获取”的。 （尽管这不是标准术语。您应该在加载后订购第一个障碍后说代码。）

---

了解Linux内核是如何处理此问题的，这是有用的，它们具有手动滚动的原子和受支持的有限的一组编译器。在以下位置搜索“依赖项” https://github.com/torvalds/linux/blob/master/Documentation/memory-barriers.txt，并注意if(flag) data.load()之类的“控制依赖项”与data[idx].load之类的数据依赖项之间的区别。

IIRC，即使依赖项像mo_consume这样的条件，即使C ++也不能保证if(x.load(consume)) tmp=y.load();依赖项排序。

请注意，例如，如果只有两个可能的值，则编译器 有时会将数据依赖项转换为控件依赖项。这将破坏mo_consume，并且如果值来自mo_consume加载或[[carries_dependency]]函数arg，则将是不允许的优化。这就是为什么很难实现的部分原因。这将需要教授大量有关数据依赖关系排序的优化途径，而不是仅仅期望用户编写不会执行通常会优化掉的事情的代码。 （就像tmp -= tmp;）