为什么将memory_order作为std::atomic函数的运行时参数提供

Question

store和load等std::atomic函数接受std::memory_order参数。参数可以在运行时确定，就像任何其他函数参数一样。但是，实际值可能会影响编译期间代码的优化。请考虑以下几点：

std::atomic<int> ai1, ai2;
int value = whatever;

void foo() {
    std::memory_order memOrd = getMemoryOrder();
    register int v = value; // load value from memory
    ai1.store(v, memOrd);   // dependency on v's value
    ai2.store(1, memOrd);   // no dependency. could this be move up?
}

如果memOrd恰好是memory_order_relaxed，则可以安全地将第二个存储移到第一个存储之前。这将在加载value和使用它之间增加一些额外的工作，这可能会阻止原本需要的停滞。但是，如果memOrd为memory_order_seq_cst，则不允许切换存储，因为如果ai1设置为1，则其他线程可能会依赖已设置为value的ai2。

我想知道的是为什么内存顺序被定义为运行时参数而不是编译时。在决定最好的内存操作语义之前，是否有人有理由在运行时检查环境？

Answer 1

之所以将其实现为运行时参数而不是编译时参数，是为了支持组合。

假设您正在编写一个函数，该函数使用所提供的原子操作来执行与加载操作等效的操作，但是操作在更高级别的构造上。通过将存储器顺序指定为运行时参数，高级加载然后可以将由用户提供的存储器顺序参数传递给低级原子操作，该低级原子操作是提供排序所需的，而高级操作不必是模板。

通常，原子指令将是内联的，如果内存顺序参数实际上是编译时常量，则编译器将消除对它的测试。

Answer 2

它只是一个接口规范，允许在运行时指定memory_order。它不要求实现使用这种余量。

例如，在x86硬件上，无论您指定什么，memory_order_seq_cst可能就是您所获得的。由于硬件缓存一致性协议的原因，memory_order_relaxed不可用。

在其他硬件上，您可能能够针对编译时已知的顺序进行优化，实现可能会提供利用默认参数的额外重载。

Answer 3

C++的作者本可以将memory_order实现为编译时特性，而不是运行时特性。然而，他们不会从中获得任何好处。任何能够理解内存顺序的编译器都会很容易地优化像x.load(memory_order_acq)这样显而易见的情况，因此它们不会从作为编译时特性中受益。

同时，使用运行时功能意味着他们不必为内存顺序引入任何新的符号。它们只是函数参数。这意味着它们获得了与编译时版本相同的好处，但复杂度更低。

同时，它对于更简单的编译器来说非常方便，因为它们可以像普通类一样实现原子，而不必特殊对待它。

T atomic<T>::compare_exchange_strong(T& compare, T exchange, memory_order order)
{
    lockBeforeUsing(order); // handle the acquire part of the memory order
    if (mValue == compare) {
        compare = mValue;
        mValue = compare;
    } else {
        compare = mValue;
    }
    lockAfterUsing(order); // handle the release part of the memory order
}