内存级别/栅栏（ Memory Barriers / Fences ）

翻译自：Martin Thompson – Memory
Barriers/Fences

在这篇文章里，我将讨论并发编程里最基础的技术–以内存关卡或栅栏著称。那让进程内的内存状态对其它进程可见。

CPU 使用了非常多技术去尝试和适应这种事实：CPU 运行单元的性能已远远超出主内存性能。在我的“Writing
Combining”文章，我仅仅是谈及当中一种技术。

CPU 使用的用来隐藏内存延迟的最普通技术是管线化指令。然后付出巨大努力和资源去尝试重排序这些管线来最小化缓存不命中的有关迟延。

当一个程序运行的时候。它不在乎。假设重排序后的指令提供了一样的终于结果。比如，在一个循环内。假设循环内没有操作使用循环计算器。循环计数器什么时候更新是不在乎的。编译器和 CPU 自由地重排序指令来最大化地利用 CPU，直到下一次迭代即将開始时才更新它（循环计数器）。

也可能，在一个循环的运行过程中。这个变量可能存储在一个寄存器里。永远不会推到缓存或主内存。因此，它对其他 CPU 永远不可见。

CPU 核包括多个运行单元。

比如。一个现代的Intel CPU 包括6个运行单元。能够做一组数学。条件逻辑和内存操作的组合。每一个运行单元能够做这些任务的组合。

这些运行单元并行地操作，同意指令并行地运行。假设从其他 CPU 来观察，这引入了程序顺序的还有一层不确定性。

终于，但缓存不命中发生时，现代 CPU 能够依据内存载入的结果做一个如果，然后基于这个如果继续运行直至实际数据的载入完毕。

提供“程序顺序”保留了 CPU 和编译器自由地做它们觉得能够提升性能的事情。

载入（load）和存储（store）到缓存和主内存是被缓冲和重排序的，使用载入（load），存储（store），和写组合（writing-combining）缓存。

这些缓存是关联的队列，同意高速查找。这样的查找是必须的，当一个稍后的载入须要读取一个之前存储的、还没有到达缓存的值时。上图描绘了现代多核 CPU 的简化视图。它显示了运行单元怎样使用本地寄存器和缓存来管理内存，与缓存子系统来回传送。

在多线程环境下，须要採用一些技术来让程序结果及时可见。

我不会在这篇文章里涉及缓存一致性。只如果一旦内存被推到缓存。然后有一个协议消息将发生。以确保全部共享数据的缓存是一致的。这样的使内存对处理器核可见的技术被称为内存关卡或栅栏。

内存关卡提供了两种属性。首先，它们保留了外部可见的程序顺序。通过确保全部的、关卡两側的指令表现出正确的程序顺序。假设从其它CPU观察。第二，它们使内存可见，通过确保数据传播到缓存子系统。

内存关卡是一个复杂的主题。它们在不同的 CPU 架构上的实现是很不同的。Intel CPU 有一个关联的强内存模型。本篇将以 x86 CPU 为基础解说。

存储关卡（store barrier）

存储关卡，在x86 上是”sfence”指令，强迫全部的、在关卡指令之前的存储指令在关卡曾经发生，而且让 store buffers 刷新到公布这个指令的 CPU cache。这将使程序状态对其它 CPU 可见，这样，假设须要它们能够对它做出响应。一个实际的好样例是以下的、简化的、来自Disruptor的类BatchEventProcessor。当sequence被更新后。其它消费者和生产者知道这个消费者的进展。并进行适当的响应。全部在关卡之前对内存的更新如今都可见了。

private volatile long sequence = RingBuffer.INITIAL_CURSOR_VALUE;

// from inside the run() method

T event = null;

long nextSequence = sequence.get() + 1L;

while (running)

{

    try

    {

       //  译注：barrier 会读取其它sequence 的值。所以这里面有个 load barrier 指令。

        final long availableSequence = barrier.waitFor(nextSequence);

        while (nextSequence <= availableSequence)

        {

            event = ringBuffer.get(nextSequence);

            boolean endOfBatch = nextSequence == availableSequence;

            eventHandler.onEvent(event, nextSequence, endOfBatch);

            nextSequence++;

        }

        sequence.set(nextSequence - 1L);

        // store barrier 插入到这里 !!!

    }

    catch (final Exception ex)

    {

        exceptionHandler.handle(ex, nextSequence, event);

        sequence.set(nextSequence);

        // store barrier 插入到这里 !!!

        nextSequence++;

    }

}

载入关卡（load barrier）

载入关卡。在x86 上是”lfence”指令，强迫全部的、载入指令之后的指令在关卡之后发生，然后等待那个 CPU 的 load buffer 排空。

这使其他 CPU 暴露出来的程序状态对这个 CPU 可见。在做出很多其他进展之前。

这个的一个好样例是前面引用的 BatchEventProcessor 的 sequence 被其他生产者或消费者读取时，Disruptor 里有等价的指令。

Full Barrier

Full Barrier。在x86 上是”mfence”指令，在 CPU 上是载入和存储关卡的组合。

Java 存储模型（Java Memory Model）

在Java 存储模型里，volatile 字段在写入后插入一个存储关卡，在读取前插入载入关卡。类里面修饰为 final 的字段在它们被初始化后插入一个存储指令，以确这些字段在构造函数完毕、有可用引用到这个对象时是可见的。

原子指令和软件锁（Atomic Instructions and Software Locks）

原子指令，如x86里的 “lock …” 指令，是高效的 full barrier，它们锁住存储子系统来运行操作。有受保证的全序关系（total order），即使跨 CPU。软件锁通常使用存储关卡，或原子指令来达到可视性和保留程序顺序。

存储关卡对性能的影响（Performance Impact of Memory Barriers）

存储关卡阻止了 CPU 运行非常多隐藏内存延迟的技术，因此有它们有显著的性能开销，必须考虑。为了达到最大性能。最好对问题建模，这样处理器能够做工作单元，然后让全部必须的存储关卡在工作单元的边界上发生。採用这样的方法同意处理器不受限制地优化工作单元。

把必须的存储关卡分组是故意的，那样，在第一个之后的 buffer 刷新的开销会小点。由于没有工作须要进行又一次填充它。

译注：关于Disruptor能够看我之前的这篇文章：http://coderbee.net/index.php/open-source/20130812/400

原文地址：http://coderbee.net/index.php/concurrent/20131211/624;