【转】解密内存屏障

简介：以下虽非java内存屏障的例子，但很大具有参考对比性）

对大多数应用层开发者来说，“内存屏障”（memory barrier）是一种陌生，甚至有些诡异的技术。
实际上，他常被用在操作系统内核中，用于实现同步机制、驱动程序等。
利用它，能实现高效的无锁数据结构，提高多线程程序的性能表现。
本文首先探讨了内存屏障的必要性，之后介绍如何使用内存屏障实现一个无锁唤醒缓冲区（队列），用于在多个线程间进行高效的数据交换。

x = r;
y = 1;

编译时，编译器优化进行指令重排而导致内存乱序访问；
运行时，多CPU间交互引入内存乱序访问。

// thread 1
while(!ok);
do(x);
 
// thread 2
x = 42;
ok = 1;

int x, y, r;
void f()
{
    x = r;
    y = 1;
}

movl    r(%rip), %eax
movl    %eax, x(%rip)
movl    $1, y(%rip)

movl    r(%rip), %eax
movl    $1, y(%rip)
movl    %eax, x(%rip)

#define barrier() __asm__ __volatile__("": : :"memory")

int x, y, r;
void f()
{
    x = r;
    __asm__ __volatile__("": : :"memory")
    y = 1;
}

volatile int x, y, r;

#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))

int x, y, r;
void f()
{
    ACCESS_ONCE(x) = r;
    ACCESS_ONCE(y) = 1;
}

运行时，CPU本身是会乱序执行指令的。
早期的处理器为有序处理器（in-order processors）,总是按开发者编写的顺序执行指令，
如果指令的输入操作对象（input operands）不可用（通常由于需要从内存中获取），
那么处理器不会转而执行那些输入操作对象可用的指令，而是等待当前输入操作对象可用。
相比之下，乱序处理器（out-of-order processors）会先处理那些有可用输入操作对象的指令（而非顺序执行）从而避免了等待，提高了效率。
现代计算机上，处理器运行的速度比内存快很多，有序处理器花在等待可用数据的时间里已可处理大量指令了。
即便现代处理器会乱序执行，但在单个CPU上，指令能通过指令队列顺序获取并执行，结果利用队列顺序返回寄存器堆
（详情可参考http:// http://en.wikipedia.org/wiki/Out-of-order_execution），这使得程序执行时所有的内存访问操作看起来像是按程序代码编写的顺序执行的，
  因此内存屏障是没有必要使用的（前提是不考虑编译器优化的情况下）。

(1). 穿透(Write through)模式，每次写时，都直接将数据写回内存中，效率相对较低；
(2). 回写(Write back)模式，写的时候先写回告诉缓存，然后由高速缓存的硬件再周转复用缓冲线(Cache Line)时自动将数据写回内存，
     或者由软件主动地“冲刷”有关的缓冲线(Cache Line)。

// thread 0 -- 在CPU0上运行
x = 42;
ok = 1;
 
// thread 1 – 在CPU1上运行
while(!ok);
print(x);

#define barrier() __asm__ __volatile__("": : :"memory") 
#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2) 
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)
 
#ifdef CONFIG_SMP 
#define smp_mb() mb() 
#define smp_rmb() rmb() 
#define smp_wmb() wmb() 
#define smp_read_barrier_depends() read_barrier_depends() 
#define set_mb(var, value) do { (void) xchg(&var, value); } while (0) 
#else 
#define smp_mb() barrier() 
#define smp_rmb() barrier() 
#define smp_wmb() barrier() 
#define smp_read_barrier_depends() do { } while(0) 
#define set_mb(var, value) do { var = value; barrier(); } while (0) 
#endif

volatile int x, y, r1, r2;
//thread 1
void run1()
{
    x = 1;
    r1 = y;
}
 
//thread 2
void run2
{
    y = 1;
    r2 = x;
}

void run1()
{
    x = 1;
    //CPU内存屏障，保证x=1在r1=y之前执行
    __asm__ __volatile__("mfence":::"memory");
    r1 = y;
}
 
//thread 2
void run2
{
    y = 1;
    //CPU内存屏障，保证y = 1在r2 = x之前执行
    __asm__ __volatile__("mfence":::"memory");
    r2 = x;
}

1，sfence. Performs a serializing operation on all store-to-memory instructions that were issued prior the SFENCE instruction. 
This serializing operation guarantees that every store instruction 
that precedes in program order the SFENCE instruction is globally visible before any store instruction 
that follows the SFENCE instruction is globally visible. The SFENCE instruction is ordered with respect store instructions, 
other SFENCE instructions, any MFENCE instructions, and any serializing instructions (such as the CPUID instruction). 
It is not ordered with respect to load instructions or the LFENCE instruction.
也就是说sfence确保：sfence指令前后的写入(store/release)指令，按照在sfence前后的指令序进行执行。
写内存屏障提供这样的保证: 所有出现在屏障之前的STORE操作都将先于所有出现在屏障之后的STORE操作被系统中的其他组件所感知.
[!] 注意, 写屏障一般需要与读屏障或数据依赖屏障配对使用; 参阅"SMP内存屏障配对"章节. 
(译注: 因为写屏障只保证自己提交的顺序, 而无法干预其他代码读内存的顺序. 所以配对使用很重要. 其他类型的屏障亦是同理.)

2，lfence. Performs a serializing operation on all load-from-memory instructions 
that were issued prior the LFENCE instruction. This serializing operation guarantees 
that every load instruction that precedes in program order the LFENCE instruction is globally visible before any load instruction that 
follows the LFENCE instruction is globally visible. The LFENCE instruction is ordered with respect to load instructions, 
other LFENCE instructions, any MFENCE instructions, and any serializing instructions (such as the CPUID instruction). 
It is not ordered with respect to store instructions or the SFENCE instruction. 
也就是说lfence确保：lfence指令前后的读取(load/acquire)指令，按照在mfence前后的指令序进行执行。
读屏障包含数据依赖屏障的功能, 并且保证所有出现在屏障之前的LOAD操作都将先于所有出现在屏障之后的LOAD操作被系统中的其他组件所感知.
[!] 注意, 读屏障一般要跟写屏障配对使用; 参阅"SMP内存屏障的配对使用"章节.

3，mfence. Performs a serializing operation on all load-from-memory and store-to-memory instructions 
that were issued prior the MFENCE instruction. This serializing operation guarantees that every load and store instruction 
that precedes in program order the MFENCE instruction is globally visible before any load or store instruction 
that follows the MFENCE instruction is globally visible. 
The MFENCE instruction is ordered with respect to all load and store instructions, 
other MFENCE instructions, any SFENCE and LFENCE instructions, and any serializing instructions (such as the CPUID instruction). 
也就是说mfence指令：确保所有mfence指令之前的写入(store/release)指令，都在该mfence指令之后的写入（store/release）指令之前（指令序，Program Order）执行；
同时，他还确保所有mfence指令之后的读取（load/acquire）指令，都在该mfence指令之前的读取（load/acquire）指令之后执行。
即：既确保写者能够按照指令序完成数据写入，也确保读者能够按照指令序完成数据读取。
通用内存屏障保证所有出现在屏障之前的LOAD和STORE操作都将先于所有出现在屏障之后的LOAD和STORE操作被系统中的其他组件所感知.

void run1()
{
    x = 1;
    //CPU内存屏障，保证x=1在r1=y之前执行
    __asm__ __volatile__("sfence":::"memory");
    r1 = y;
}
 
//thread 2
void run2
{
    y = 1;
    //CPU内存屏障，保证y = 1在r2 = x之前执行
    __asm__ __volatile__("sfence":::"memory");
    r2 = x;
}

通用屏障，保证读写操作有序，包括mb()和smp_mb();
写操作屏障，仅保证写操作有序，包括wmb()和smp_wmb();
读操作屏障，仅保证读操作有序，包括rmb()和smp_rmb();

// thread 1
x = 42;
smb_wmb();
ok = 1;
 
// thread 2
while(!ok);
smb_rmb();
do(x);

unsigned int __kfifo_put(struct kfifo *fifo,
            const unsigned char *buffer, unsigned int len)
{
    unsigned int l;
 
    len = min(len, fifo->size - fifo->in + fifo->out);
 
    /*
     * Ensure that we sample the fifo->out index -before- we
     * start putting bytes into the kfifo.
         * 通过内存屏障确保先读取fifo->out后，才将buffer中数据拷贝到
         * 当前fifo中
     */
 
    smp_mb();
 
    /* first put the data starting from fifo->in to buffer end */
        /* 将数据拷贝至fifo->in到fifo结尾的一段内存中 */
    l = min(len, fifo->size - (fifo->in & (fifo->size - 1)));
    memcpy(fifo->buffer + (fifo->in & (fifo->size - 1)), buffer, l);
 
        /* then put the rest (if any) at the beginning of the buffer */
        /* 如果存在剩余未拷贝完的数据（此时len – l > 0）则拷贝至 
         * fifo的开始部分
         */
    memcpy(fifo->buffer, buffer + l, len - l);
 
    /*
     * Ensure that we add the bytes to the kfifo -before-
     * we update the fifo->in index.
     */
        /*
         * 通过写操作屏障确保数据拷贝完成后才更新fifo->in
         */
 
    smp_wmb();
 
    fifo->in += len;
 
    return len;

unsigned int __kfifo_get(struct kfifo *fifo,
             unsigned char *buffer, unsigned int len)
{
    unsigned int l;
 
    len = min(len, fifo->in - fifo->out);
 
    /*
     * Ensure that we sample the fifo->in index -before- we
     * start removing bytes from the kfifo.
     */
        /*
         * 通过读操作屏障确保先读取fifo->in后，才执行另一个读操作：
         * 将fifo中数据拷贝到buffer中去
         */
 
    smp_rmb();
 
    /* first get the data from fifo->out until the end of the buffer */
        /* 从fifo->out开始拷贝数据到buffer中 */
    l = min(len, fifo->size - (fifo->out & (fifo->size - 1)));
    memcpy(buffer, fifo->buffer + (fifo->out & (fifo->size - 1)), l);
 
    /* then get the rest (if any) from the beginning of the buffer */
        /* 如果需要数据长度大于fifo->out到fifo结尾长度，
         * 则从fifo开始部分拷贝（此时len – l > 0）
         */
    memcpy(buffer + l, fifo->buffer, len - l);
 
    /*
     * Ensure that we remove the bytes from the kfifo -before-
     * we update the fifo->out index.
     */
        /* 通过内存屏障确保数据拷贝完后，才更新fifo->out */
 
    smp_mb();
 
    fifo->out += len;
 
    return len;
}

索引in和out被两个线程访问。in和out指明了缓冲区中实际数据的边界，也就是in和out同缓冲区数据存在访问上的顺序关系，
由于不适用同步机制，那么保证顺序关系就需要使用到内存屏障了。
索引in和out都分别只被一个线程修改，而被两个线程读取。
__kfifo_put先通过in和out来确定可以向缓冲区中写入数据量的多少，
这时，out索引应该先被读取，才能真正将用户buffer中的数据写入缓冲区，
因此这里使用到了smp_mb()，对应的，__kfifo_get也使用smp_mb()来确保修改out索引之前缓冲区中数据已被成功读取并写入用户buffer中了。
（我认为在__kfifo_put中添加的这个smp_mb()是没有必要的。理由如下，kfifo仅支持一写一读，这是前提。
在这个前提下，in和out两个变量是有着依赖关系的，这的确没错，并且我们可以看到在put中，in一定会是最新的，
因为put修改的是in的值，而在get中，out一定会是最新的，因为get修改out的值。
这里的smp_mb()显然是希望在运行时，遵循out先load新值，in再load新值。
的确，这样做是没错，但这是否有必要呢？out一定要是最新值吗？out如果不是最新值会有什么问题？
如果out不是最新值，实际上并不会有什么问题，仅仅是在put时，fifo的实际可写入空间要大于put计算出来的空间
（因为out是旧值，导致len在计算时偏小），这并不影响程序执行的正确性。
从最新linux-3.16-rc3 kernel的代码：lib\kfifo.c的实现：
__kfifo_in中也可以看出memcpy(fifo->data + off, src, l);
memcpy(fifo->data, src + l, len – l);
之前的那次smb_mb()已经被省去了，当然更新in之前的smb_wmb()还是在kfifo_copy_in中被保留了。
之所以省去这次smb_mb()的调用，我想除了省去调用不影响程序正确性外，是否还有对于性能影响的考虑，尽量减少不必要的mb调用）。
对于in索引，在__kfifo_put中，通过smp_wmb()保证先向缓冲区写入数据后才修改in索引，
由于这里只需要保证写入操作有序，所以选用写操作屏障，在__kfifo_get中，通过smp_rmb()保证先读取了in索引
（这时in索引用于确定缓冲区中实际存在多少可读数据）才开始读取缓冲区中数据（并写入用户buffer中），由于这里指需要保证读取操作有序，故选用读操作屏障。

1,对于第一类原子操作方式，显然内存屏障是需要我们考虑的，例如kernel中kfifo的实现，就必须要显示的考虑在数据写入和读取时插入必要的内存屏障，以保证程序执行的顺序与我们设定的顺序一致。
2,对于使用gcc内建的原子操作访问接口，基本上大多数gcc内建的原子操作都自带内存屏障，他可以确保在执行原子内存访问相关的操作时，执行顺序不被打断。“In most cases, these builtins are considered a full barrier. That is, no memory operand will be moved across the operation, either forward or backward. Further, instructions will be issued as necessary to prevent the processor from speculating loads across the operation and from queuing stores after the operation.”（http://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html）。当然，其中也有几个并未实现full barrier，具体情况可以参考gcc文档对对应接口的说明。同时，gcc还提供了对内存屏障的封装接口：__sync_synchronize (…)，这可以作为应用程序使用内存屏障的接口(不用写汇编语句)。
3,对于使用libatomic库进行原子操作，原子访问的程序。Libatomic在接口上对于内存屏障的设置粒度更新，他几乎是对每一个原子操作的接口针对不同平台都有对应的不同内存屏障的绑定。“Provides implementations for atomic memory update operations on a number of architectures. This allows direct use of these in reasonably portable code. Unlike earlier similar packages, this one explicitly considers memory barrier semantics, and allows the construction of code that involves minimum overhead across a variety of architectures.”接口实现上分别添加了_release/_acquire/_full等各个后缀，分别代表的该接口的内存屏障类型，具体说明可参见libatomic的README说明。如果是调用最顶层的接口，已AO_compare_and_swap为例，最终会根据平台的特性以及宏定义情况调用到：AO_compare_and_swap_full或者AO_compare_and_swap_release或者AO_compare_and_swap_release等。我们可以重点关注libatomic在x86_64上的实现，libatomic中，在x86_64架构下，也提供了应用层的内存屏障接口：AO_nop_full

如果你在程序中是裸着写内存，读内存，则需要显式的使用内存屏障确保你程序的正确性，gcc内建不提供简单的封装了内存屏障的内存读写，
因此，如果只是使用gcc内建函数，你仍然存在裸读，裸写，此时你还是必须显式使用内存屏障。
如果你通过libatomic进行内存访问，在x86_64架构下，使用AO_load/AO_store，你可以不再显式的使用内存屏障
（但从实际使用的情况来看，libatomic这类接口的效率不是很高）