原文：http://preshing.com/20120515/memory-reordering-caught-in-the-act/

编写lock-free C/C++程序时，在保证memory ordering正确性上要非常小心，否则，奇怪的事就来了。Intel在《x86/64 Architecture Specification》Volume 3, §8.2.3一节中列出了一些可能发生的“怪事”。来看一个小例子：X，Y两个变量均被初始化为0，编写如下汇编代码，由两个处理器(processor)执行：

为了清楚的阐述CPU ordering，此处使用了汇编指令。每个处理器将一个变量赋值为1(store)，并读取另外一个变量(load)，此处的r1、r2代表寄存器。正常情况下，不管处理器的执行顺序如何，r1，r2所有可能的结果为：

r1==0, r2 ==1 
r1==1, r2==0
r1==1, r2==1

不可能的结果为:

r1==0, r2==0。

按Intel文档中的描述，上述结果是有可能的，这就是本文所要讲述的“怪事”（至少是违反直觉的）。
Intel x86/x64处理器和大多数处理器家族一样，在不影响单个线程执行结果的前提下，允许对内存交互指令进行重排(reorder)。特别指出：处理器允许将store动作延迟到任何load动作之后,只要load、store的操作的不是同一块内存。因此，您编写的汇编代码在执行时可能变成了这样：

来，试试！

“好好好，你说这事可能发生，但我从来没见过，叫我如何相信？”
那...叫我们来试试如何：源码在这。
这份代码包括win32、POSIX两个版本，由两个派生线程重复执行上述transaction代码，并由主线程核对执行结果。
第一个工作线程源码如下：x, y, r1, r2为全局变量，两个POSIX semaphores用于和主线程的并发处理：

第二个线程处理类似，只需将r1换成r2，beginSema1换成beginSema2

sem_t beginSema1;
sem_t endSema;
int X, Y;int r1, r2;
void *thread1Func(void *param)
{
   MersenneTwister random(1);                // Initialize random number generator
   for (;;)                                  // Loop indefinitely
   {
       sem_wait(&beginSema1);                // Wait for signal from main thread
       while (random.integer() % 8 != 0) {}  // Add a short, random delay

       // ----- THE TRANSACTION! -----
       X = 1;
       asm volatile("" ::: "memory");        // Prevent compiler reordering
       r1 = Y;

       sem_post(&endSema);                   // Notify transaction complete
   }
   return NULL;  // Never returns
};

在每个事务之前添加一个短暂的随机延迟，以便错开线程的时序。记住，有两个工作线程，我们试图让他们的指令重叠（译注：这两句话似乎是矛盾的）。随机延迟是使用与之前的帖子中使用的相同的MersenneTwister来实现的，例如在测量锁争用时以及验证递归的Benaphore是否工作时。别被asm volatile这行代码唬到，这只是告诉GCC编译器在生成机器码时，不要重排store和load，以防GCC在编译优化时又想出了什么“歪点子”。

来看编译后的汇编代码：

$ gcc -O2 -c -S -masm=intel ordering.cpp
$ cat ordering.s
    ...
    mov    DWORD PTR _X, 1
    mov    eax, DWORD PTR _Y
    mov    DWORD PTR _r1, eax
    ...

Store和load的顺序和预期的一致，先执行X=1，随后执行r1=Y。

下面是主线程代码，职责如下：初始化后，进入无限循环，重置x，y为0，通过信号量触发两个线程运行。
需要注意的是：所有写入共享内存的方式都是在sem_post之前发生的，所有从共享内存读取的数据都是在sem_wait之后发生的。在与主线程通信时，工作线程遵循相同的规则。信号量给我们在每个平台上获取和释放语义。这意味着我们保证X = 0和Y = 0的初始值将正确传递到工作线程，并且r1和r2的结果值将从工作线程传递到主线程。换句话说，信号量避免在框架中出现内存重排序，让我们完全专注于实验本身！

int main()
{
    // Initialize the semaphores
    sem_init(&beginSema1, 0, 0);
    sem_init(&beginSema2, 0, 0);
    sem_init(&endSema, 0, 0);

    // Spawn the threads
    pthread_t thread1, thread2;
    pthread_create(&thread1, NULL, thread1Func, NULL);
    pthread_create(&thread2, NULL, thread2Func, NULL);

    // Repeat the experiment ad infinitum
    int detected = 0;
    for (int iterations = 1; ; iterations++)
    {
        // Reset X and Y
        X = 0;
        Y = 0;
        // Signal both threads
        sem_post(&beginSema1);
        sem_post(&beginSema2);
        // Wait for both threads
        sem_wait(&endSema);
        sem_wait(&endSema);
        // Check if there was a simultaneous reorder
        if (r1 == 0 && r2 == 0)
        {
            detected++;
            printf("%d reorders detected after %d iterations\n", detected, iterations);
        }
    }
    return 0;  // Never returns
}

检验真理的时刻到了，这是我在Intel Xeon W3520、Cygwin环境下运行的结果：

【译】Memory Reordering Caught in the Act_第1张图片

这下你总算信了吧！运行过程中，内存重排序大约每6600次检测到一次。当我在Core 2 Duo E6300、Ubuntu 环境下测试时，出现的概率甚至更低。你已经开始意识到， bugs在未被发现的情况下蔓延到lock-free代码中。现在，你可能在想：“我不需要这该死的reording”。OK，至少有两种方法。
一种是将两个线程绑定到同一个CPU core上，pthread并未提供相应的结构，但linux上可以这样做：

   cpu_set_t cpus;
   CPU_ZERO(&cpus);
   CPU_SET(0, &cpus);
   pthread_setaffinity_np(thread1, sizeof(cpu_set_t), &cpus);
   pthread_setaffinity_np(thread2, sizeof(cpu_set_t), &cpus);

这样一来，重排序消失了。因为单个处理器上是保序的，哪怕线程在任意时候被抢占并重新调度。当然，将两个线程绑定到一个核上，致使其它CPU Core未被有效利用(由此看来，这并不是个好办法)。
我在Playstation 3上编译、运行，并未检测到内存重排。这表明（但不确认）PPU内的两个硬件线程可能会有效地作为单个处理器，具有非常细粒度的硬件调度。

采用StoreLoad Barrier避免memory reordering

另一种避免memory reordering的方法是：在两条指令间引入CPU屏障(CPU Barrier)。本例中，我们要阻止Store和随后的Load指令发生重排，引入的CPU Barrier通常称为StoreLoad Barrier。

在X86/X64处理器上，没有专门的StoreLoad barrier指令，但有一些指令可完成另丰富的功能。Mfence指令为full memory barrier指令，它可以避免任何情况的内存重排。GCC中的实现方式如下：

   for (;;)                                  // Loop indefinitely
   {
       sem_wait(&beginSema1);                // Wait for signal from main thread
       while (random.integer() % 8 != 0) {}  // Add a short, random delay

       // ----- THE TRANSACTION! -----
       X = 1;
       asm volatile("mfence" ::: "memory");  // Prevent memory reordering
       r1 = Y;

       sem_post(&endSema);                   // Notify transaction complete
   }

查看编译生成的汇编代码来验证效果：

    ...
    mov    DWORD PTR _X, 1
    mfence
    mov    eax, DWORD PTR _Y
    mov    DWORD PTR _r1, eax
    ...

修改后，内存重排消失了，两个线程可运行在两个不同的CPU cores上。

类似的指令和不同的平台

其实，mfence不是x86/x64下唯一的full memory barrier。在这些处理器上，任何locked指令，如xchg均属于full memory barrier - 只要您不使用SSE指令或write-combined memory，像本示例一样。实际上，如果你使用MemoryBarrier指令时，Microsoft C++编译器会生成xchg指令(至少VS2008如此)。

Mfence指令适用于x86/x64，如果想编写可移植的代码，可以采用预处理宏技术。Linux内核提供了一组宏：smp_mb、smp_rmb、smp_wmb，并提供了一组实现alternate implementations on different architectures. 如在PowerPC上，smp_mb被实现为sync.

不同的CPU家族有其自己的memory ordering指令集，编译器根据自身喜好提供此类功能，而跨平台项目则为此封装自己的抽象层...而这些对简化lock-free编程毫无益处。这也是为何C++11引入C++11 atomic library标准的原因，标准化、更为方便的编写lock-free的可移植代码。

译注：

Memory Reordering准确的理解应该是和Memory相关的机器指令的重排序。
Memory Reordering将其认定同类的或访问相同内存的CPU指令尽可能的放到一起执行。
Memory Reording的原则在于：重排前后，单个线程上的行为保持一致，前述例子中，每个程序单独运行时其结果是一致的，也可以理解为“保序”。
在编写多线程程序时，我们通常通过添加mutex、semaphores 等方式执行并发保护，而非lock-free程序。这类锁按本文的描述均属于full memory barrier，程序当然不会出现memory reordering问题。

【译】Memory Reordering Caught in the Act

来，试试！

采用StoreLoad Barrier避免memory reordering

类似的指令和不同的平台

你可能感兴趣的:(【译】Memory Reordering Caught in the Act)