C++ std::memory_order_relaxed 和跳过/停止标志

Question

是否可以使用std::memory_order_relaxed 作为跳过标志，如iterate：

    constexpr static const std::size_t capacity = 128; 
    std::atomic<bool> aliveness[capacity];
    T data[capacity];     // immutable/atomic/etc.

    template<class Closure>
    void iterate(Closure&& closure){
        for(std::size_t i = 0; i<capacity; i++){
            if (!aliveness[i].load(std::memory_order_relaxed)) continue;                    
            closure( data[i] );
        }
    }

    void erase(std::size_t index){
        aliveness[index].store(false, std::memory_order_relaxed);
    }

或者我应该使用 release/acquire 来代替？

aliveness[i] 可能会再次“活着”。

iterate 和 erase 同时从多个线程调用。考虑data immutable/atomic/synchronized 在其他一些外部锁下。

Answer 1

假设：当您使用erase 时，其他线程可以随时运行iterate()。 （该问题的早期版本没有指定不可变。如果更新data[i] 的锁定（或缺少锁定）未按顺序写入alive[i]，则此答案仍然相关。）

如果数据确实是不可变的，那么mo_relaxed 绝对没问题，除非您需要根据线程正在执行的操作else 对这些商店的全局可见性进行排序。 mo_relaxed 存储最终将始终对其他线程可见（在当前的 CPU 上，这样做会非常快）。

---

如果您要修改非原子data[i] 而alive[i] 为假，您需要确保其他线程在修改它时没有使用它的值。那将是 C++ 中的 UB，而实际硬件上的实际正确性问题取决于 T 和 closure。

获取语义适用于iterate。对data[i] 的访问逻辑上发生在alive[i] 之后，因为单向障碍的方向正确。 The acquire-load won't reorder with later loads or stores, only earlier ones.

但是erase 的商店有问题。在对data[i] 进行任何修改之前，它必须是全局可见的。但是发布商店可以与后来的商店重新订购。你需要的是a release fence to block reordering of stores in both directions。

void erase(std::size_t index){
    aliveness[index].store(false, std::memory_order_relaxed);
    std::atomic_thread_fence(std::memory_order_release);
  // or don't do that, this probably wouldn't be enough synchronization
  // and whatever you do that syncs the data might make this unnecessary.
}

如果T 是原子类型，则data[i] 的发布存储就可以解决问题。但不要那样做；如果T 太大而不能成为无锁原子，那就太糟糕了。

(更新：我不确定这是否完全有效。ISO C++ 内存排序规则是根据 synchronizes-with/happens-before 定义的，以及允许给定负载的值看。不是在原子操作和非原子操作之间重新排序本身。

此外，这就像您对 SeqLock 所做的那样，但这也取决于数据争用 UB 进行读取。如果另一个线程要读取data[i]，如果它检查alive[i] 然后读取，则存在TOCTOU 竞赛：我们对alive 的写入可能发生在读取之后，然后我们对data[i] 的写入可能与另一个线程同时发生线程阅读。 所以这可能不足以擦除/修改/取消擦除元素，即使在像 x86 这样的强排序非怪异机器上也是如此。）

---

在某些实现中，seq-cst 存储也可以工作，但我认为仅作为实现细节。它通常会导致存储 + 全屏障 asm 指令。 （例如 x86 MFENCE）。所以它之所以有效，只是因为编译器将 seq-cst 存储实现为 store + thread_fence(seq_cst)。在 AArch64 上情况并非如此，因为 STLR 只是一个释放操作；只有与 LDAR 的交互才能产生 SC-DRF。 （seq_cst 用于无数据竞争的程序）。

---

请注意，如果closure 修改data[]，iterate 是不安全的，除非一次只有一个线程可以调用它。在这种情况下，这有什么意义？所以可能你应该使用

void iterate(Closure&& closure) const
{ ... }

所以iterate 仅适用于容器的const 对象。