我试着寻找这方面的细节，我什至阅读了关于互斥锁和原子的标准......但我仍然无法理解 C++11 内存模型可见性保证。 据我了解，互斥互斥的非常重要的特性是确保可见性。也就是每次只有一个线程增加计数器是不够的，重要的是线程增加最后使用互斥锁的线程存储的计数器(我真的不知道为什么人们在讨论时不提这个互斥体，也许我有不好的老师:))。 因此，据我所知， atomic 不会强制立即可见: (来自维护 boost::thread 并实现了 c++11 线程和互斥库的人):

A fence with memory_order_seq_cst does not enforce immediate visibility to other threads (and neither does an MFENCE instruction). The C++0x memory ordering constraints are just that --- ordering constraints. memory_order_seq_cst operations form a total order, but there are no restrictions on what that order is, except that it must be agreed on by all threads, and it must not violate other ordering constraints. In particular, threads may continue to see "stale" values for some time, provided they see values in an order consistent with the constraints.

我同意。但问题是我很难理解关于原子的 C++11 构造是“全局的”，并且只能确保原子变量的一致性。 特别是，我了解以下哪些(如果有)内存排序保证在加载和存储之前和之后会有一个内存栅栏: http://www.stdthread.co.uk/doc/headers/atomic/memory_order.html

据我所知，std::memory_order_seq_cst 插入了内存屏障，而其他只强制对特定内存位置的操作进行排序。

所以有人可以澄清一下吗，我想很多人会使用 std::atomic 制造可怕的错误，尤其是如果他们不使用默认值(std::memory_order_seq_cst 内存排序)
2.如果我是对的，这是否意味着此代码中的第二行是多余的:

atomicVar.store(42);
std::atomic_thread_fence(std::memory_order_seq_cst);  

3。从某种意义上说，std::atomic_thread_fences 是否与互斥锁具有相同的要求，以确保非原子变量的 seq 一致性必须执行 std::atomic_thread_fence(std::memory_order_seq_cst); 加载前和 std::atomic_thread_fence(std::memory_order_seq_cst);
在商店之后？
4.是

  {
    regularSum+=atomicVar.load();
    regularVar1++;
    regularVar2++;
    }
    //...
    {
    regularVar1++;
    regularVar2++;
    atomicVar.store(74656);
  }

相当于

std::mutex mtx;
{
   std::unique_lock<std::mutex> ul(mtx);
   sum+=nowRegularVar;
   regularVar++;
   regularVar2++;
}
//..
{
   std::unique_lock<std::mutex> ul(mtx);
    regularVar1++;
    regularVar2++;
    nowRegularVar=(74656);
}

我认为不是，但我想确定一下。

编辑: 5. 能断言火吗？
只有两个线程存在。

atomic<int*> p=nullptr; 

第一个线程写入

{
    nonatomic_p=(int*) malloc(16*1024*sizeof(int));
    for(int i=0;i<16*1024;++i)
    nonatomic_p[i]=42;
    p=nonatomic;
}

第二个线程读取

{
    while (p==nullptr)
    {
    }
    assert(p[1234]==42);//1234-random idx in array
}

最佳答案

如果你喜欢处理栅栏，那么 a.load(memory_order_acquire) 相当于 a.load(memory_order_relaxed) 后跟 atomic_thread_fence(memory_order_acquire) 。类似地，a.store(x,memory_order_release) 相当于在调用 a.store(x,memory_order_relaxed)< 之前调用="">atomic_thread_fence(memory_order_release)/。 memory_order_consume 是 memory_order_acquire 的一个特例，仅用于相关数据。 memory_order_seq_cst 是特殊的，它构成了所有 memory_order_seq_cst 操作的总顺序。与其他混合，它与加载的获取和存储的释放相同。 memory_order_acq_rel用于read-modify-write操作，相当于RMW的read部分的acquire和write部分的release。

对原子操作使用排序约束可能会也可能不会产生实际的栅栏指令，具体取决于硬件架构。在某些情况下，如果您将排序约束放在原子操作上而不是使用单独的栅栏，编译器会生成更好的代码。

在 x86 上，加载始终是获取的，而存储始终是释放的。 memory_order_seq_cst 需要使用 MFENCE 指令或 LOCK 前缀指令进行更强的排序(这里有一个实现选择，是否使存储具有更强的排序或负载)。因此，独立的获取和释放栅栏是无操作的，但 atomic_thread_fence(memory_order_seq_cst) 不是(再次需要 MFENCE 或 LOCK ed 指令) .

排序约束的一个重要影响是它们对其他操作进行排序。

std::atomic<bool> ready(false);
int i=0;

void thread_1()
{
    i=42;
    ready.store(true,memory_order_release);
}

void thread_2()
{
    while(!ready.load(memory_order_acquire)) std::this_thread::yield();
    assert(i==42);
}

thread_2 旋转直到它从 ready 读取 true。由于在 thread_1 中存储到 ready 是一个释放，并且加载是一个获取，因此存储 同步 加载，并且存储到 i happens-before 在断言中从 i 加载，并且断言不会触发。

2)

atomicVar.store(42);
std::atomic_thread_fence(std::memory_order_seq_cst);  

确实可能冗余，因为存储到 atomicVar 默认使用 memory_order_seq_cst。但是，如果此线程上有其他非memory_order_seq_cst 原子操作，则栅栏可能会产生后果。例如，它将充当后续 a.store(x,memory_order_relaxed) 的释放栅栏。

3) 栅栏和原子操作不像互斥锁那样工作。您可以使用它们来构建互斥锁，但它们不像它们那样工作。您不必使用 atomic_thread_fence(memory_order_seq_cst)。不要求任何原子操作都是 memory_order_seq_cst，并且可以在没有的情况下实现对非原子变量的排序，如上例所示。

4) 不，这些不相等。因此，没有互斥锁的代码段是数据竞争和未定义的行为。

5) 不，您的断言不能触发。使用 memory_order_seq_cst 的默认内存顺序，来自原子指针 p 的存储和加载就像我上面示例中的存储和加载一样工作，并且保证在读取之前发生对数组元素的存储.

关于c++ - 内存模型排序和可见性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7461484/