go内存模型

OStack程序员社区-中国程序员成长平台 › 门户 › 编程› Go›Go教程

原作者: [db:作者] 来自: [db:来源] 收藏邀请

重排？？？

https://blog.csdn.net/FJDJFKDJFKDJFKD/article/details/113179262

------------------------------

注：Memory Ordering at Compile Time，译文内容有删减。

在源码编写和最终可执行文件在处理器上执行期间，代码中的内存交互行为可能根据相应的规则被重排序。内存重排序可以在编译阶段和运行时（处理器）发生。采用这样做的原因是为了更好的运行性能。

编译器开发人员和 CPU 供应商普遍遵循的内存重排序的基本规则如下：

内存重排序不应当修改单线程程序的行为。

基于上面的规则，内存重排序对编程人员写单线程程序时几乎不察觉。因为采用了各种同步互斥机制 (mutex, semaphore, etc)，在多线程程序中也基本不感知。只有在无锁化编程中才会明显地体会到内存重排序的影响。无锁化编程中内存在各个线程间共享而没有任何互斥手段 (mutual exclusion) 加以保护。

编译器指令重排序 Compiler Instruction Reordering

众所周知，编译器的工作就是讲人类易读的源代码转换成机器可识别的机器码。在这个转换期间，编译器有很多自由度进行代码调整以优化性能等。

在遵循上面提到的不改变单线程程序的行为规则下，指令重排序通常在优化选项开启的情况下才会进行。参见下面的代码段：

int A, B;

void foo()
{
    A = B + 1;
    B = 0;
}

如果我们不开启优化选项，gcc 7.3.0 将生成如下的代码。对 B 的赋值在对 A 的赋值之后，这和我们在源代码中看到的一样。

$ gcc -S -masm=intel foo.c
$ cat foo.s
        ...
        mov     eax, DWORD PTR B[rip]
        add     eax, 1
        mov     DWORD PTR A[rip], eax
        mov     DWORD PTR B[rip], 0
        ...

如果开启 -O2 优化选项，可以看到编译器把对 B 的赋值操作到对 A 赋值之前了，当然上面提到的规则并没有被破坏，因为单线程程序并不感知这里的区别。

$ gcc -O2 -S -masm=intel foo.c
$ cat foo.s
        ...
        mov     eax, DWORD PTR B[rip]
        mov     DWORD PTR B[rip], 0
        add     eax, 1
        mov     DWORD PTR A[rip], eax
        ...

另一方面，编译器的这种行为在无锁化编程中将可能导致问题。下面是一个被经常引用的例子，一个共享的标识变量用来表征某些其他的共享变量被更新。

int Value;
int IsPublished = 0;

void sendValue(int x)
{
    Value = x;
    IsPublished = 1;
}

想象一下假如 IsPublished 被提前到 Value 被更新将会导致什么。即使是在单处理器系统上，这也会导致问题：该线程很可能在上面两个赋值间被其他线程抢占，这使得其他线程感知到 Value 已经被更新，但实际上并没有更新。

当然编译器可能不会做上面这么极端的重排序，最终无锁化编程的代码在强内存序 CPU 的多核系统或者任意 CPU 类型的单处理器系统上也不会有问题。其他场景的话我们只能自求多福。不用多说，更好的做法是认识到对共享变量进行内存重新排序的可能性，并确保强制执行正确的排序。

显式的编译器屏障 Explicit Compiler Barriers

阻止编译器重排序的最简单的方法是指定一个特殊的标志，即编译器屏障。

int A, B;

void foo()
{
    A = B + 1;
    asm volatile("" ::: "memory");
    B = 0;
}

有了编译器屏障，我们可以放心使能编译优化选项，得到期望的不重排序效果。

$ gcc -O2 -S -masm=intel foo.c
$ cat foo.s
        ...
        mov     eax, DWORD PTR B[rip]
        add     eax, 1
        mov     DWORD PTR A[rip], eax
        mov     DWORD PTR B[rip], 0
        ...

编译器屏障可以保证单处理器系统的内存重排序问题，但是目前多核处理器已是主流。各种设备都在堆核心的路上高歌猛进。如果我们希望代码在各种 CPU 架构的多处理器系统上也能正常工作，光有编译器屏障是不够的。我们还需要处理器屏障指令 (CPU fence instruction)。

Linux 内核通过宏提供了多种处理器的屏障指令，如 smp_rmb，这些宏会在目标架构下展开成不同的底层屏障指令。

隐式的编译器屏障 Implied Compiler Barriers

还有其他方式阻止编译器重排序，前文提到的处理器屏障指令行为和编译器屏障类似。下面是一个 PowerPC 的处理器屏障指令。

#define RELEASE_FENCE() asm volatile("lwsync" ::: "memory")

代码中可以插入上面的宏来阻止编译器重排序，并且还提供了一些处理器重排序的语义。

在 C++11 原子库标准中，每个非 relaxed 的原子操作也均表现出编译器屏障的作用。

int Value;
std::atomic<int> IsPublished(0);

void sendValue(int x)
{
    Value = x;
    // <-- reordering is prevented here!
    IsPublished.store(1, std::memory_order_release);
}

正如你所想的那样，每个包含编译器屏障的函数本身也表现出编译器屏障的作用，即使这个函数被内联。

void doSomeStuff(Foo* foo)
{
    foo->bar = 5;
    sendValue(123);       // prevents reordering of neighboring assignments
    foo->bar2 = foo->bar;
}

实际上，大多数函数调用本身就有编译器屏障的作用，与它们是否含有编译器屏障指令无关，除了内联函数、函数声明带有 pure 属性或者采用了链接时代码生成技术。除去上面的例外场景，一个外部函数（extern function）调用本身甚至强于编译器屏障，因为此时编译器无法确定函数的副作用，它只能忽略对潜在的对被调函数可见的内存所做的所有假设。

在上面的代码片段中，假设 sendValue 实现在外部的库中。编译器无法确定 sendValue 是否依赖于 foo->bar，也无法确定它不会修改 foo->bar。因此编译器必须遵循源码中指定的内存操作顺序，它不能对 sendValue 周围的操作进行重排序，并且还得从内存中重新加载 foo->bar 赋值给 foo->bar2，而不是假设它的值还是 5，即使此时优化选项已经开启。

$ gcc -O2 -S -masm=intel dosomestuff.c
$ cat dosomestuff.s
        ...
        mov     rbx, rdi
        mov     DWORD PTR [rdi], 5
        mov     edi, 123
        call    sendValue
        mov     eax, DWORD PTR [rbx]
        mov     DWORD PTR [rbx+4], eax
        ...

无中生有的 store 指令 Out-Of-Thin-Air Stores

在 C++11 标准之前，实际上技术上没有什么方式阻止编译器采用更激进的小把戏。特别的，编译器甚至可以产生源码中不存在的 store 指令。下面是一个非常简单的例子：

int A, B;

void foo()
{
    if (A) {
        B++;
    }
}

虽然实际情况中很少出现，但是并不能阻止编译器在检查 A 的值之前把 B 提升为一个寄存器变量，最终的代码等价于：

void foo()
{
    register int r = B;    // Promote B to a register before checking A.
    if (A) {
        r++;
    }
    B = r;          // Surprise! A new memory store where there previously was none.
}