多线程编程中什么情况下需要加 volatile？

一个来自知乎的回答，感觉很好

作者：KE meng
链接：https://www.zhihu.com/question/31459750/answer/52061391
来源：知乎

作者知乎主页https://www.zhihu.com/people/ke-meng-90/answers
著作权归作者所有，转载请联系作者获得授权。

另外一个总结的比较全的关于volatile的回答：https://www.zhihu.com/question/29037280

来看这个代码:

int fun(int& a)
{
    int b = a;
    int c = a;
    return a+b+c;
}

int main()
{
    int a=1;
    //.........做一些和a无关的事
    return fun(a);
}

这个代码是很好优化的,因为编译器知道a的值是1,参考上下文,编译器又能知道b和c的值也是1,
而且根本没有人用到了a,b,c三个变量,也没有任何人在修改a,b,c三个的值,所以编译器可能就直接
把这个函数优化成:

int main() { return 3; }

了.

这么优化有什么问题吗? 单线程没问题,但多线程就有问题了,如果是多线程,
a的值虽然在当前上下文中不会被修改,但可能正在被其他线程修改啊.于是上面的优化
就不对了. 那么,volatile关键字在这里就可以帮助我们了,volatile关键字提醒编译器:
a可能随时被 意外修改.
意外的意思是虽然当前这段代码里看起来a不会变,但可能别的地方正在修改a的值哦.
所谓"别的地方",某些情况下指的就是其他线程了.

那么,如果把代码修改如下:

int fun(volatile int& a)
{
    int b = a;
    int c = a;
    return a+b+c;
}

int main()
{
    volatile int a=1;
    //.........做一些和a无关的事
    return fun(a);
}

编译器就不敢优化了:

int fun(volatile int& a)
{
    int b = a; //这里从内存读一下a吧,谁知道a还等不等于1呢
    int c = a; //这里再从内存读一下a吧,谁知道a还等不等于1呢
    return a+b+c;  //这里也从内存读一下a吧,谁知道a还等不等于1呢
}

int main()
{
    volatile int a=1;
    //.........做一些和a无关的事
    return fun(a); //完全不敢优化啊,鬼知道a变成多少了....
}

同理的,这段代码:

//..........
int a=0;
//做一些和a无关的事
if(a==0) doSomething();
//..........

编译器会发现,a肯定等于0啊,那我还if个毛啊,直接优化掉!

//..........
int a=0;
//做一些和a无关的事
doSomething(); //if被去掉了
//..........

但,一旦添加了volatile,编译器就不敢优化了.例如:

//..........
volatile int a=0;
//做一些和a无关的事
if(a==0) doSomething(); //可不敢优化这里! 谁知道a变成多少了!
//..........

这便是volatile的作用了.

必须补充说明,volatile和锁没有一毛钱的关系,该加锁依然需要加锁.给变量添加volatile并不会让其自动拥有一个锁.所以该加锁还得加.

//------------------- 更新答案 -------------------------------------------

感谢大家的鼓励,受宠若惊! 重新看了一下答案,感觉还可以再补充一下,再举一个例子吧:

网上教程里经常见到双检锁保证单例模式的代码,简化一下,大概逻辑如下:

static int* instance;

int& get_instance()
 {
    if( !instance ) { //检查如果单例的指针是0
        此处有某种锁; //则在此处上锁
	if( !instance ) {  //再判断一次,以防等待锁期间有别的线程已经new完了
 	    instance = new int; //确认无误则new之
	}
    }
    return *instance;
}

int main()
{
    int& i = get_instance();
    i = 111;
    return 1;
}

耳听为虚眼见为实,咱们看看反汇编如何(Intel ICC,O2,为了方便看反汇编禁用inline):

...................
010B1034  mov         eax,dword ptr ds:[010B5100h] //读取instance指针到eax
010B1039  test        eax,eax //检查eax是否为0
010B103B  je          get_instance+12h (010B1042h) //如果为0,则跳转下文010B1042处
...................
010B103D  //此处为下文中跳回的位置
...................
010B1041  ret                 //get_instance()函数返回
................... //010B1042从这里开始
010B1044  call        dword ptr ds:[10B309Ch] //这里面call进去是malloc函数  
010B104A  add         esp,4 //调整栈
010B104D  mov         dword ptr ds:[010B5100h],eax//将malloc出的写回instance地址
010B1052  jmp         get_instance+0Dh (010B103Dh) //跳回前面的代码
.........................

反汇编发现什么问题没? 喂! 判断只做了一次啊!!!! 第二个if去哪里了!
哪里去了? 被编译器优化掉了.... 因为这里的优化逻辑很简单:
如果第一个判断某值==0成功,根本没必要去做第二个判断,因为编译器能发现此值没被这段代码
修改,同时编译器认为此值也不会被其他人"意外"修改,于是,苦心积虑所做的双检锁失效了.跟没写一样.

好了,见证奇迹的时候到了,我们就改一行代码:

static int* volatile instance;

再编译一下,看看反汇编:

01201034  mov         eax,dword ptr ds:[01205100h]  //读取instance指针到eax
01201039  test        eax,eax  //检查eax是否为0
0120103B  je          get_instance+17h (01201047h)//如果为0,则跳转下文01201047h处
.................
01201046  ret  //get_instance()函数返回
.................
//以下为上文中跳转位置01201047:
01201047  mov         eax,dword ptr ds:[01205100h] //再次读取instance指针到eax
0120104C  test        eax,eax  //再次检查eax是否为0
0120104E  jne         get_instance+0Dh (0120103Dh) //如果非0,跳回上文return处
01201050  push        4  //如果还是0,往下执行malloc什么的.
01201052  call        dword ptr ds:[120309Ch] //这里进去是malloc
...........
0120105B  mov         dword ptr ds:[01205100h],eax //将malloc好的值写回instance
01201060  jmp         get_instance+0Dh (0120103Dh) //返回上文
...........

终于,双检锁的逻辑正确了.因为volatile已经提示编译器,instance指针可能被"意外"修改.不要瞎做优化.

这里有一个要吐槽的,intel ICC用最高等级优化,不加volatile的话连第一个判断都被优化掉了,
而MSVC无论怎么开优化,加不加volatile,永远两个判断全做,不愧是安全第一...

特别提醒: 实际上即使加了volatile,这样的双检锁依然不安全,只有原子操作才安全,
详情请见我的另一个答案:
对int变量赋值的操作是原子的吗？ - 知乎用户的回答

//------------------------------------

评论区有朋友问是否多线程都要加volatile,首先,无论加不加volatile关键字,
任何多线程同时读/写变量,不加锁不用原子操作,则都是race condition,
在C++11标准中,race condition是未定义行为.这样做就跟*((int*)0)=1一样危险.
所以,上文中的双检锁依然是危险的.因为对instance本身的读写没有锁,且是非原子的.

但是,回到现实中,很多锁或者大部分原子操作都附带memory read/write barrier,
一定程度上可以保证内存读写的顺序不会被编译器瞎优化.确实能避免一些危险.
至于memory barrier能不能就完全替代volatile了,基本可以确定是不能,但我水平有限,举不出例子.

最后的最后归纳一下吧,多线程读写变量? 要安全? 加volatile! 加原子操作/锁!

PS: 如果想转载请署我名且通知我,因为这样我会好爽好爽