[译]Atomic VS. Non-Atomic 操作

原文链接：atomic-vs-non-atomic-operations

 

     在网上已经写了很多关于原子操作的文章，但是通常都集中在原子的读-修改-写（RMW. read-modify-write）操作。但是这些并是所有的原子操作。同样重要的属于原子操作的还是有load（译注：读）和store（译注：写）。在这篇文章中，我将会在处理器层面和C/C++语言层面，比较原子性和非原子性的load和store。顺便，我们将会阐明以下在C++11中的“数据竞争”概念。

   

     如果一个共享变量的操作，它能相对于其他线程，能够一步完成，那么这个操作就是原子性的操作。当对一个共享变量执行原子性的store操作，其他线程只能观察到它已经修改完后的数据。当对一个共享变量执行原子性的load操作，它会读取单一时刻所显示的完整的值。非原子性的store和load不会有上述的保证。

     离开上述的保证，无锁编程(lock-free programming)将变得不可能，因为不能在相同时间，让多个线程操作同一个共享变量。我们可以将此明确表达为一个规则：

任何时间，两个线程并发地操作在一个共享变量上，这些操作中的一个执行一个写动作，所有的线程都必须使用原子操作。

     如果你违反这个规则，其中有个线程使用了非原子操作，那么你将会陷入一个在C++11标准中称之为数据竞争（不要和Java中的data race概念，以及更通用的race condition搞混淆）的情形。C++11标准没有告诉编程人员为什么数据竞争是不好的。但是如果你引发了数据竞争，那么就会得到一个"未定义行为（undefined behavior）"的结果。数据竞争是不好的真正理由只有一个：它们会导致“撕裂读”（torn reads）和“撕裂写”（torn writes。译注：就是一个非完整的读写）。

    一个内存操作可能是非原子的，因为它使用了多条CPU指令，甚至即使使用单条CPU指令，也可能是非原子的。也可能是因为程序员写的可移植代码。但是不能简单地做出这个假设。让我们看几个例子。

 

由于多条CPU指令的非原子操作

假设有一个64位的全局变量，初始化为0.

uint64_t sharedValue = 0;

此时，将一个64位的值更新到此变量：

void storeValue()
{
    sharedValue = 0x100000002;
}

在32位的 x86平台上，使用GCC编译此函数，会产生以下汇编代码：

$ gcc -O2 -S -masm=intel test.c
$ cat test.s
        ...
        mov    DWORD PTR sharedValue, 2
        mov    DWORD PTR sharedValue+4, 1
        ret
        ...

      如你所见，编译器实现一个64位整形的赋值是通过两个单独的机器指令。第一条指令将低32位设置为0x00000002，第二条指令将高32位设置为0x00000001。很明显，这个赋值操作不是原子操作。如果sharedValue被不同线程并发访问，将会出错。

1. 如果一个线程在两条指令之间对sharedValue的访问时独占的，那么在内存中，sharedValue将会被设置为0x0x0000000000000002，
   一个“撕裂写（a torn write）”。此时，如果另外一个线程读取sharedValue的值，那么将会读到一个完全虚假的值。
2. 更遭的是，如果一个线程在两条指令之间进行独占访问，此时另一个在第一个线程恢复前修改变量sharedValue，会
   导致一个永久性的“撕裂写（torn write）”：高32位来源于一个线程，低32位来源于另一个线程。
3. 在多核设备中，线程都没必要进行一个会导致“撕裂写”的资源抢占。因为当一个线程调用sharedValue，在不同核心上的
   任意线程在某个时刻都可能会去读sharedValue，此时的sharedValue可能处于修改的一半当中。

并发地从sharedValue读也会带来一些问题：

uint64_t loadValue()
{
    return sharedValue;
}

$ gcc -O2 -S -masm=intel test.c
$ cat test.s
        ...
        mov    eax, DWORD PTR sharedValue
        mov    edx, DWORD PTR sharedValue+4
        ret
        ...

      同样，编译器用两条机器指令实现读取操作：第一条指令读取低32位的值到eax寄存器，然后第二条指令读取高32位的值到edx寄存器。在这种情况下，并发地发生一个写的操作，此时会产生一个“撕裂读（torn read）”。即使这个并发的写是原子操作。

      这些问题并不只是存在于理论上。Mintomic的测试套件中包含了一个叫test_load_store_64_fail的测试用例。一个线程使用普通的赋值操作符更新一个64位变量的值，另一个线程周期性地执行一个从相同变量的读取操作，对每次读取回来的结果进行校验。在x86多核机器上，和预期一样，此测试会经常失败。

 

非原子性的CPU指令

     即使执行单条CPU指令，一个内存操作也可能是非原子性的。例如：在ARMv7指令集中，包含了一个strd指令，实现将两个32位的寄存器的值存储到一个64位的变量中。

strd r0, r1, [r2]

      在一些ARMv7处理器中，这条指令时非原子性的。当处理器碰到这条指令时，实际上是执行2条32位的单独存储动作。再一次，任何运行在其他核心的线程都可能会观察到一个“撕裂读（torn write）”。有意思的是，“撕裂读（torn write）”甚至可能会发生在单核设备中：因为系统中断。在2条32位存储指令中间，可能会发生线程上下文的调度切换。这种情况下，当线程从中断中恢复后，将会重新执行一次strd指令。

     另外一个例子，是发生在大家熟知的x86平台上。一个32位的mov指令只有在内存操作数是自然对齐的情况下才是原子性的！其他情况下是非原子性的。换句话说，一个32位的整形，只有它的内存地址是4的整数倍情况下，原子性才能有保证。Mintomic有另一个测试用例test_load_store_32_fail，可以验证此种情况。在写本文的时候（译注：2013年6月），这个测试用例在x86平台上总是成功的。但是如果你将测试变量sharedInt的地址强制修改为非对齐的内存地址，那么测试结果将会失败。在我的Core 2 Quad Q6600机器上，如果sharedInt是跨越了单条缓存行界限（crosses a cache line boundary），那么测试就会失败。

// Force sharedInt to cross a cache line boundary:
#pragma pack(2)
MINT_DECL_ALIGNED(static struct, 64)
{
    char padding[62];
    mint_atomic32_t sharedInt;
}
g_wrapper;

对于特定处理的情况已经说的够多了，接下来看看在C/C++语言层面的原子性。

 

所有的C/C++操作都假设是非原子性的

       在C和C++中，每一个操作都被假定为非原子性的，即使是普通的32位整形赋值。除非编译器或硬件厂商有特殊说明。

uint32_t foo = 0;

void storeFoo()
{
    foo = 0x80286;
}

      语言标准中没有提及关于以上情况的原子性。也许整形赋值是原子性的，也许不是。因为非原子性的操作不做任何保证，所以在C中定义普通的整形赋值时非原子性的。

      在实际中，我们通常更了解我们的目标平台。例如：在所有的现代x86，x64，Itanium，SPARC，ARM和PowerPC处理器中，普通的32位整形，只要内存地址是对齐的，那么赋值操作就是原子操作。你可以通过查看处理器手册或者编译器文档来证实。在游戏产业，很多32位的赋值时依赖于这个特别的保证。

      尽管如此，当写真正的可移植的C和C++代码时，有一个长期的伪装的传统就是，我们只知道语言标准中所记录的，除此之外，一概不知。可移植的C/C++代码是要运行在每台可能的设备上，过去的设备，现在的设备以及想象中的设备。从我个人来说，我喜欢想象有台机器，只能被一开始的混乱所改变。

      在这样的机器上，你绝对不会想在同一时间执行并发的读操作，即使是普通的赋值。你可能最终只会读到一个完全随机的值。
      在C++11中，有一种方式可以真正执行可移植的load原子操作和store原子操作：C++11 atomic库。使用C++11 atomic库，即使是运行在想象的机器上，也可以执行原子性的load和store。即使在C++11 atomic库的内部秘密地使用互斥锁使每个操作变得原子性。同样还有一个我上个月发布的叫Mintomic的库（译注：2013年6月，此库目前已废。）。虽然支持的平台可能不多，但是在几个老的编译器上还是可以正常工作的，它是手工优化的并且保证是无锁的。

 

不严格的(Relaxed)原子操作

      让我们回到原来的sharedValue例子。我们将会使用Mintomic对其进行重写。这样在Mintomic支持的平台上，所有的操作都是原子性的了。首先，必须将sharedValue声明为Mintomic的原子数据类型的一种。

#include <mintomic/mintomic.h>

mint_atomic64_t sharedValue = { 0 };

      mint_atomic64_t类型在不同的平台上，保证原子访问都有正确的内存对齐。这很重要。因为在一些平台的编译器中并不做出类似的保证。比如ARM上的和Xcode 3.2.5绑定的GCC4.2版，就不保证普通的uint64_t是8字节对齐的。

在修改sharedValue时，不再调用普通的、非原子的赋值操作，而是调用mint_store_64_relaxed

void storeValue()
{
    mint_store_64_relaxed(&sharedValue, 0x100000002);
}

同样的，在读取sharedValue变量的值时，我们使用mint_load_64_relaxed

uint64_t loadValue()
{
    return mint_load_64_relaxed(&sharedValue);
}

      使用C++11的术语来说，上述方法是无数据竞争（data race-free）的。在执行并发操作时，绝对不可能存在“撕裂读”或“撕裂写”。不管是运行在ARMv6/ARMv7，x86，x64或PowerPC。

下面是C++11的版本

#include <atomic>

std::atomic<uint64_t> sharedValue(0);

void storeValue()
{
    sharedValue.store(0x100000002, std::memory_order_relaxed);
}

uint64_t loadValue()
{
    return sharedValue.load(std::memory_order_relaxed);
}

      你可能注意到，不管Mintomic还是C++11版本的代码都使用了relaxed语义的原子操作，也就是带有_relaxed后缀的内存序列参数。

      特别地，关于relaxed语义的原子操作，在此原子操作的之前或者之后的指令都可能被影响，也就是被乱序执行。可能是因为编译器指令乱序或者处理器的指令乱序。编译器可能还是在重复的relaxed原子操作上做一些优化，就像在非原子性的操作上一样。在所有的情况下，这个操作都是原子操作。

      当并发地操作共享变量，一贯地使用C++11 atomic库或者Mintomic是个好习惯，即使是你知道在你所针对的平台上，普通的load或store操作已经是原子操作。一个atomic库的方法可以起到一个提示作用，提示这个变量是并发访问的。