Mutex和内存可见性

介绍

POSIX线程遵守共享内存模型^[1]，此模型各线程可以访问一组共享对象。多个并发的线程需要协同访问共享对象。为此该模型引入了以下两个属性来简化程序设计：

原子访问：避免线程在访问数据对象时，另一线程正在修改它。 内存可见性：一旦线程修改数据对象，其它线程在修改行为发生之后马上能看见此对象的新状态，如图1所示。

Mutex通常被引进作为实现原子访问的手段，但它的作用不仅仅是用来控制对象访问，还解决内存可见性问题。接下来将看到，某些场景下，并不需要关心原子访问题，往往内存可见性才是问题所在。此场景之下如果没有mutex，那将是一场恶梦……

图1：预期的内存可见性。线程A设置x=6和y=7，线程B在其后执行z=x*y，我们期望获取z=42的结果。

mutex解决弱内存可见性

下面是marathon程序。基本上，线程A应该一直在运行，直到线程B设置arrived变量的值来通知它，才运行结束。

Marathon程序

01 volatile bool  arrived = false; 02  03 volatile float miles   = 0.0; 04  05/*--- Thread A ----------------------------------------*/ 06  07 while (!arrived) 08  09{ 10  11    run(); 12  13} 14  15 printf("miles run: %f\n", miles); 16  17/*-----------------------------------------------------*/ 18  19/*--- Thread B ----------------------------------------*/ 20  21 miles   = 26.385; // 42.195 Km 22  23 arrived = true; 24  25/*-----------------------------------------------------*/

这里没有使用mutex来控制arrived标志的访问。这样的代码我见过不少，并且听到一大萝的解释：

“因为仅仅有一个线程读，一个线程写，所以不需要使用mutex”

“就算arrived标志的值是随机值，也是非零值，根据C语言约定它为true。因此while循环最终会停下来。这里不需要关心原子性，因此不需要mutex”

“对于本例子，使用mutex除了增加几行代码，还拖慢了程序，毫无必要”

“通过压力测试，程序确实运行正确”

在各自的平台上，这些说法几乎是正确的。话虽如此，但这个程序仍然是有问题的。把它运行在其它平台上，会遇到莫名其妙的错误。

硬件优化

在某些平台上，线程A可能会如期停止，但它会打印 miles run 0.0。而在另一些平台上，线程甚至可能不会停止，即使用线程B已将arrived标志修改为true。

想不通了吧？这些怪诞行为的始作俑者就是硬件平台。更确切地说是硬件对内存访问实施了优化。一般来说，CPU指令执行的速度比从主存读取数据的速度 要快2到3个数量级。显然内存子系统是整个系统的屏颈，硬件工程师使尽浑身解数想出聪明办法来使访问内存更快。首先是使用cache来加速内存访问，然而 这带来了下面这些额外的复杂性：

当cache访问不命中时，处理仍然难逃被内存子系统拖慢的厄运。在多处理器系统，必须使用协议保存cache一致性。

乱序执行

我们知道编译器会通过重排指令来优化程序的执行时间。但鲜为人知的是，现在处理器同样会根据需要乱序执行指令，以对付上面谈及的问题1）。

为了理解乱序执行是如何工作的，请看下面伪汇编写的简单例子：

乱序执行

1 mov r1, mem  // load mem cell to register r1 2  3 add r1,r1,r2 // r1 = r1+r2 4  5 add r3,r4,r5 // r3 = r4+r5</pre>

在实际执行中，内存单元mem的值可能不在cache中，因此需要从主存中获取。这种情况下，处理器会按如下顺序来执行，以窃取等待读取内存完成的空档：

第一行指令被执行后，处理器不会等待内存访问完成。

在第一行指令执行后，马上调度执行第二行指令。

因为寄存器操作数可用，并且与第一行指令和第二行指令没有依赖关系，所以处理器可以马上执行第三行指令。

因此处理器的执行顺序可能是：(3)-(1)-(2)，而非按原序执行。它带来的好处是：处理器可以利用从内存总数获取数据而停滞100或更多地时 钟周期做更有意义的事情，以提高执行速度。当然，这种优化对于当前执行指令的线程是完全透明的（译注：即这种乱序执行对当前线程的程序语义没有任何改 变）。

然而，乱序执行会被其它线程观察到。如果线程B（在乱序执行时）先设置arrived标志的值为true，那么可能线程A结束时，打印出miles的值并非线程B所修改后的。真不可思议！……

Store Buffer

当处理器所读取的内存是多处理器系统的共享内存时，事情变得更复杂。必须使用协议来保证，当某变量的最新值保存到CPU的cache时，其它所有 CPU的cache上该变量的副本必须更改成无效状态，以在所有处理器上保持值的一致性。这种协议的缺点是CPU在写数据时，不可避免地受到了拖延。

硬件工程再度想出聪明的解决方法：将写请求缓冲到一个称为store buffer的特殊硬件队列。所有请求都放到队列里，随后CPU方便时一下子将修改请求应用内存里。

对于软件开发人员，更关心的问题时，何时谓之方便。上面的marathon程序可能会发生这样的场景，‘arrived=true‘请求已排队到store buffer，但store buffer上的请求永远都不对主存生效。因此线程A永远也看不到标志变量的新值。Oops!……

内存屏障

之前所见的种种怪异事情，均可发生在现代硬件上。这种内存可见性比我们所认为的逊色多了，那么如何在这种架构上编写可预知的程序呢？

这下该内存屏障(memory barriers，别称membars, memory fences, mfences)出场了。内存屏障是一种特殊的处理器指令，它指挥处理器做如下的事情：

刷新store buffer。等待直到内存屏障之前的操作已经完成。不将内存屏障后面的指令提前到内存屏障之前执行

通过适当使用内存屏障，可以确保它之前的乱序执行已全部完成，并且未完成的写操作已经全部刷新到主存。因此，数据一致性又重回到其它线程的身边，从而保证正确的内存可见性。因此可大胆猜测：mutex实现根据需要使用了恰当的内存屏障。

如果对内存屏障和硬件优化感兴趣，推荐阅读Paul Mckenny^[2]的优秀论文。

真实的例子

到目前为止，讨论的话题是相当理论的。本节给出一个具体的例子，由于没有正确使用内存可见性，而导致怪异的结果(只是偶尔出现)。本例来自于Bartosz Milewski的文章^[3]和演讲^[4]。

请看下面的程序mutex_01.c。程序创建两个线程，通过Arun和Brun标志变量，可以配置成某个线程先运行，或者两者并发运行。Pthtrad barrier(请不要与内存屏障混肴)用于确保两个线程在同一时刻启动。一旦两线程都运行完成，断言(Astate==1 || Bstate==1)有效。如果断言失败，则打印一条消息。整个程序依次按此过程无限循环执行。

下载 mutex_01.c

001</pre> 002 </div> 003 <div>/*------------------------------- mutex_01.c --------------------------------* 004On Linux, compile with: 005cc -std=c99 -pthread mutex_01.c -o mutex_01 006  007Check your system documentation how to enable C99 and POSIX threads on 008other Un*x systems. 009  010Copyright Loic Domaigne. 011Licensed under the Apache License, Version 2.0. 012*--------------------------------------------------------------------------*/ 013  014#define _POSIX_C_SOURCE 200112L // use IEEE 1003.1-2004 015  016#include // sleep() 017#include #include 018#include // EXIT_SUCCESS 019#include // strerror() 020#include 021  022/***************************************************************************/ 023/* our macro for errors checking */ 024/***************************************************************************/ 025#define COND_CHECK(func, cond, retv, errv) \ 026 if ( (cond) ) \ 027{ \ 028  fprintf(stderr, "\n[CHECK FAILED at %s:%d]\n| %s(...)=%d (%s)\n\n",\ 029  __FILE__,__LINE__,func,retv,strerror(errv)); \ 030  exit(EXIT_FAILURE); \ 031} 032  033#define ErrnoCheck(func,cond,retv) COND_CHECK(func, cond, retv, errno) 034#define PthreadCheck(func,rc) COND_CHECK(func,(rc!=0), rc, rc) 035  036/*****************************************************************************/ 037/* real work starts here */ 038/*****************************************************************************/ 039/* 040  * Accordingly to the Intel Spec, the following situation 041  * 042  * thread A: thread B: 043  * mov [_x],1 mov [_y],1 044  * mov r1,[_y] mov r2,[_x] 045  * 046  * can lead to r1==r2==0. 047  * 048  * We use this fact to illustrate what bad surprise can happen, if we don't 049  * use mutex to ensure appropriate memory visibility. 050  * 051  */ 052 volatile int Arun=0; // to mark if thread A runs 053 volatile int Brun=0; // dito for thread B 054  055 pthread_barrier_t barrier; // to synchronize start of thread A and B. 056  057/*****************************************************************************/ 058/* threadA- wait at the barrier, set Arun to 1 and return Brun */ 059/*****************************************************************************/ 060 void* 061 threadA(void* arg) 062{ 063  pthread_barrier_wait(&barrier); 064  Arun=1; 065  return (void*) Brun; 066} 067  068/*****************************************************************************/ 069/* threadB- wait at the barrier, set Brun to 1 and return Arun */ 070/*****************************************************************************/ 071 void* 072 threadB(void* arg) 073{ 074  pthread_barrier_wait(&barrier); 075  Brun=1; 076  return (void*) Arun; 077} 078  079/*****************************************************************************/ 080/* main- main thread */ 081/*****************************************************************************/ 082/* 083  * Note: we don't check the pthread_* function, because this program is very 084  * timing sensitive. Doing so remove the effect we want to show 085  */ 086int 087main() 088{ 089  pthread_t thrA, thrB; 090  void *Aval, *Bval; 091  int Astate, Bstate; 092  093  for (int count=0; ; count++) 094  { 095  // init 096  // 097  Arun = Brun = 0; 098  pthread_barrier_init(&barrier, NULL, 2); 099  100  // create thread A and B 101  // 102  pthread_create(&thrA, NULL, threadA, NULL); 103  pthread_create(&thrB, NULL, threadB, NULL); 104  105  // fetch returned value 106  // 107  pthread_join(thrA, &Aval); 108  pthread_join(thrB, &Bval); 109  110  // check result 111  // 112  Astate = (int) Aval; Bstate = (int) Bval; 113  if ( (Astate == 0) && (Bstate == 0) ) // should never happen 114  { 115  printf("%7u> Astate=%d, Bstate=%d (Arun=%d, Brun=%d)\n", 116  count, Astate, Bstate, Arun, Brun ); 117  } 118  119  } // forever 120  121  // never reached 122  // 123  return EXIT_SUCCESS; 124 }</div> 125 <div>

这里不分析pthread_*函数，实际上，这是一个时序敏感的程序，我们只打印那些不正常的行为。

我们将跑在Core Duo的Linux下，得到下面的输出。可以看出，程序循环2500000次后有8次出现断言失效。

61586> Astate=0, Bstate=0 (Arun=1, Brun=1) 670781> Astate=0, Bstate=0 (Arun=1, Brun=1) 824820> Astate=0, Bstate=0 (Arun=1, Brun=1) 1222761> Astate=0, Bstate=0 (Arun=1, Brun=1) 1337091> Astate=0, Bstate=0 (Arun=1, Brun=1) 1523985> Astate=0, Bstate=0 (Arun=1, Brun=1) 2340428> Astate=0, Bstate=0 (Arun=1, Brun=1) 2400663> Astate=0, Bstate=0 (Arun=1, Brun=1)

内存可见性问题就是结果的唯一解释。请看下面由gcc生成的编译代码，访问Arun和Brun均是原子的(只列出线程A的代码，线程B的代码与它类似）。

线程的汇编代码：

01threadA: 02.LFB2: 03         pushq   %rbp 04.LCFI0: 05         movq    %rsp, %rbp 06.LCFI1: 07         subq    $16, %rsp 08.LCFI2: 09         movq    %rdi, -8(%rbp) 10         movl    $barrier,