c++ - 比 std::atomic 更便宜的替代品？

Question

我在多线程应用程序中有一类对象，其中每个线程都可以将一个对象标记为要删除，然后中央垃圾收集器线程实际上删除该对象。线程通过访问内部 bool 值的成员方法进行通信:

class MyObjects {
...   
bool shouldBeDeleted() const
{
   return m_Delete;
}

void
markForDelete()
{
   m_Delete = true;
}
...
   std::atomic< bool >                                        m_IsObsolete;
}

过去，由于 Thread Sanitizer 不断提示， bool 值已被其他人设为原子。然而，perf 现在表明内部原子加载期间存在处理开销:

   │     ↓ cbz    x0, 3f4                                                                                                                                                                                                                                                                                                                                                                                            

   │     _ZNKSt13__atomic_baseIbE4loadESt12memory_order():                                                                                                                                                                                                                                                                                                                                                           

   │           {                                                                                                                                                                                                                                                                                                                                                                                                     

   │             memory_order __b = __m & __memory_order_mask;                                                                                                                                                                                                                                                                                                                                                       

   │             __glibcxx_assert(__b != memory_order_release);                                                                                                                                                                                                                                                                                                                                                      

   │             __glibcxx_assert(__b != memory_order_acq_rel);                                                                                                                                                                                                                                                                                                                                                      

   │                                                                                                                                                                                                                                                                                                                                                                                                                 

   │             return __atomic_load_n(&_M_i, __m);                                                                                                                                                                                                                                                                                                                                                                 

   │       add    x0, x0, #0x40                                                                                                                                                                                                                                                                                                                                                                                          

 86,96 │       ldarb  w0, [x0]  

目标平台是 GCC、Aarch64 和 Yocto Linux。

现在我的问题如下:

• 在这种情况下真的需要原子吗？ bool 的转换是一种方式(从 false 到 true)，在对象生存期间无法返回，因此不一致仅意味着该对象稍后会被删除，对吗？

• 是否有 std::atomic<bool> 的替代方案这将使 Thread Sanitizer 静音，但计算成本比 std::atomic<bool> 便宜？

Answer 1

一个明显的修改可能是指定memory_order_relaxed以最小化内存障碍。

参见https://en.cppreference.com/w/cpp/atomic/memory_order

和https://bartoszmilewski.com/2008/12/01/c-atomics-and-memory-ordering/

另请参阅赫伯·萨特 (Herb Sutter) 的经典著作“原子武器”:https://channel9.msdn.com/Shows/Going+Deep/Cpp-and-Beyond-2012-Herb-Sutter-atomic-Weapons-1-of-2

m_Delete.store (true, std::memory_order_relaxed);

---

警告(参见上面的文章) - 如果标记为删除的对象存在任何相互依赖性(例如另一个状态变量、释放资源等)，那么您可能需要使用memory_order_release来确保可以删除标志设置发生最后并且不会被编译器优化器重新排序。

假设“垃圾收集器”仅单独检查可以删除标志，则不需要在加载中使用memory_order_acquire；放松就足够了。否则，需要使用 acquire 来保证在读取标志之前不会重新排序任何相互依赖的访问。