volatile

编译器有时候为了优化性能,会将一些变量的值缓存到寄存器中,因此如果编译器发现该变量的值没有改变的话,将从寄存器里读出该值,这样可以避免内存访问。

但是这种做法有时候会有问题。如果该变量确实(以某种很难检测的方式)被修改呢?那岂不是读到错的值?是的。在多线程情况下,问题更为突出:当某个线程对一个内存单元进行修改后,其他线程如果从寄存器里读取该变量可能读到老值,未更新的值,错误的值,不新鲜的值。

如何防止这样错误的“优化”?方法就是给变量加上volatile修饰。

volatile int i=10;//用volatile修饰变量i
......//something happened 
int b = i;//强制从内存中读取实时的i的值

OK,毕竟volatile不是完美的,它也在某种程度上限制了优化。有时候是不是有这样的需求:我要你立即实时读取数据的时候,你就访问内存,别优化;否则,你该优化还是优化你的。能做到吗?

不加volatile修饰,那么就做不到前面一点。加了volatile,后面这一方面就无从谈起,怎么办?伤脑筋。

其实我们可以这样:

int i = 2; //变量i还是不用加volatile修饰

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

需要实时读取i的值时候,就调用ACCESS_ONCE(i),否则直接使用i即可。

这个技巧,我是从《Is parallel programming hard?》上学到的。

听起来都很好?然而险象环生:volatile常被误用,很多人往往不知道或者忽略它的两个特点:在C/C++语言里,volatile不保证原子性;使用volatile不应该对它有任何Memory
Barrier
的期待。

第一点比较好理解,对于第二点,我们来看一个很经典的例子:

volatile int is_ready = 0;
char message[123];
void thread_A
{
  while(is_ready == 0)
  {
  }
  //use message;
}
void thread_B
{
  strcpy(message,"everything seems ok");
  is_ready = 1;
}

线程B中,虽然is_readyvolatile修饰,但是这里的volatile不提供任何Memory
Barrier
,因此12行和13行可能被乱序执行,is_ready = 1被执行,而message还未被正确设置,导致线程A读到错误的值。

这意味着,在多线程中使用volatile需要非常谨慎、小心。

原标题:VOLATILE与内存屏障总结

volatile关键字的使用

volatile关键字使用和const一致,下面是一个总结:

char const * pContent;       // *pContent是const,   pContent可变
(char *) const pContent;     //  pContent是const,  *pContent可变
char* const pContent;        //  pContent是const,  *pContent可变
char const* const pContent;  //  pContent 和       *pContent都是const

   

沿着*号划一条线,如果const位于*的左侧,则const就是用来修饰指针所指向的变量,即指针指向为常量;如果const位于*的右侧,const就是修饰指针本身,即指针本身是常量。

   

   

摘自 踏雪无痕

本文介绍多线程环境下并行编程的基础设施。主要包括:

  • Strong Consistency / Sequential consistency 顺序一致性
  • Release Consistency / release-acquire / release-consume
  • Relaxed Consistency

asm volatile (“” : : : “memory”);

一般编程时如果使用到volatile关键字,那么基本上都需要考虑编译器指令乱序的问题。解决编译器指令乱序所带来的问题,除了上面将必要的变量声明为volatile,还可以使用下面一条嵌入式汇编语句:

1 asm volatile ("" : : : "memory");

这是一条空汇编语句,只是告诉编译器,内存发生了变化。编译器遇到这条语句后,会生成访存更新寄存器的指令,将所有的寄存器的值更新一遍。这里是编译器遇到这条语句额外生成了一些代码,而不是CPU遇到这条语句执行了一些处理,因为这条语句本身并没有CPU指令与之对应。

由于编译器知道这条语句之后内存发生了变化,编译器在编译时就会保证这条语句上下的指令不会乱,即这条语句上面的指令,不会乱序到语句下面,语句下面的指令不会乱序到语句上面。

利用编译器这个功能,程序员可以:

1、利用这条语句,强制程序访存,而不是使用寄存器中的值,作为使用volatile关键字的一个替代手段;

2、在不允许乱序的两个语句之间插入这条语句从而保证不会被编译器乱序。

   

下面看一个应用的例子,两个线程访问共享的全局变量:

#define ARRAY_LEN 12

volatile int flag = 0;
int a[ARRAY_LEN];

pthread1()
{
    a[ARRAY_LEN – 1] = 10; <br>    asm volatile (“” : : :
“memory”);
    flag = 1;
}

pthread2()
{
    int sum = 0;

    if(flag == 0) {
        sum += a[ARRAY_LEN – 1];
    }    
}线程2假定flag==1时,线程1已经将数据放到数组中了。但实际上,如果没有 
asm volatile (“” : : : “memory”),线程1并不能保证flag =
1在数组赋值之后。原因就是我们前面提到的编译器指令乱序。

     

指令乱序是一个比较复杂的话题,我们这里只考虑了编译器指令乱序,在intel架构的CPU上,基本上考虑到这些就足够了。但在弱指令序的CPU上,比如mips,了解这些还远远不够。本文不打算展开CPU指令乱序的话题,感兴趣的可以参考以下文章了解以下:

        Memory Reordering Caught in the
Act

        This Is Why They Call It a Weakly-Ordered
CPU

   

   

volatile提醒编译器它后面所定义的变量随时都有可能改变,因此编译后的程序每次需要存储或读取这个变量的时候,都会直接从变量地址中读取数据。如果没有volatile关键字,则编译器可能优化读取和存储,可能暂时使用寄存器中的值,如果这个变量由别的程序更新了的话,将出现不一致的现象。下面举例说明。在DSP开发中,经常需要等待某个事件的触发,所以经常会写出这样的程序:
short flag;
void test()
{
do1();
while(flag==0);
do2();
}
   
这段程序等待内存变量flag的值变为1(怀疑此处是0,有点疑问,)之后才运行do2()。变量flag的值由别的程序更改,这个程序可能是某个硬件中断服务程序。例如:如果某个按钮按下的话,就会对DSP产生中断,在按键中断程序中修改flag为1,这样上面的程序就能够得以继续运行。但是,编译器并不知道flag的值会被别的程序修改,因此在它进行优化的时候,可能会把flag的值先读入某个寄存器,然后等待那个寄存器变为1。如果不幸进行了这样的优化,那么while循环就变成了死循环,因为寄存器的内容不可能被中断服务程序修改。为了让程序每次都读取真正flag变量的值,就需要定义为如下形式:
volatile short flag;
   
需要注意的是,没有volatile也可能能正常运行,但是可能修改了编译器的优化级别之后就又不能正常运行了。因此经常会出现debug版本正常,但是release版本却不能正常的问题。所以为了安全起见,只要是等待别的程序修改某个变量的话,就加上volatile关键字。

Memory Barrier

为了优化,现代编译器和CPU可能会乱序执行指令。例如:

int a = 1;
int b = 2;
a = b + 3;
b = 10;

CPU乱序执行后,第4行语句和第5行语句的执行顺序可能变为先b=10然后再a=b+3

有些人可能会说,那结果不就不对了吗?b为10,a为13?可是正确结果应该是a为5啊。

哦,这里说的是语句的执行,对应的汇编指令不是简单的mov b,10和mov b,a+3。

生成的汇编代码可能是:

movl    b(%rip), %eax ; 将b的值暂存入%eax
movl    $10, b(%rip) ; b = 10
addl    $3, %eax ; %eax加3
movl    %eax, a(%rip) ; 将%eax也就是b+3的值写入a,即 a = b + 3

这并不奇怪,为了优化性能,有时候确实可以这么做。但是在多线程并行编程中,有时候乱序就会出问题。

一个最典型的例子是用锁保护临界区。如果临界区的代码被拉到加锁前或者释放锁之后执行,那么将导致不明确的结果,往往让人不开心的结果。

还有,比如随意将读数据和写数据乱序,那么本来是先读后写,变成先写后读就导致后面读到了脏的数据。因此,Memory
Barrier
就是用来防止乱序执行的。具体说来,Memory Barrier包括三种:

1,acquire barrieracquire
barrier
之后的指令不能也不会被拉到该acquire barrier之前执行。

2,release barrierrelease
barrier
之前的指令不能也不会被拉到该release barrier之后执行。

3,full barrier。以上两种的合集。

所以,很容易知道,加锁,也就是lock对应acquire
barrier
;释放锁,也就是unlock对应release
barrier
。哦,那么full barrier呢?

1.3 CPU屏障 CPU Barrior

  指令乱序

那么什么是指令乱序,指令乱序是为了提高性能,而导致的执行时的指令顺序和代码写的顺序不一致。指令乱序有编译期间指令乱序和执行时指令乱序。

执行时指令乱序是CPU的一个特性,这块比较复杂,不再这里提及。我们只需要知道在x86/x64的体系架构下,程序员一般不需要关注执行时指令乱序(不需要关注不代表没有)。

编译期间指令乱序是指在编译成二进制代码时,编译器为了所谓的优化进行了指令重排,导致二进制指令的顺序和我们写的代码的顺序是不一致的。

比如以下代码:

int a;
int b;

int main()
{
    a = b + 1;
    b = 0;
}

会被优化成(实际上在汇编阶段进行的乱序优化,优化后的代码也只能以汇编的方式查看,这里只是拿C代码举例说明一下):

int a;
int b;

int main()
{
    b = 0;
    a = b + 1;
}

对加上volatile关键字的变量的访问,编译器不会进行指令乱序的优化,保证volatile变量的访问顺序和代码写的是一样的。比如如下代码不会优化:

volatile int a;
volatile int b;

int main()
{
    a = b + 1;
    b = 0;
}

   

但是以下代码,依然会乱序,因为编译器只是保证volatile变量访问的顺序,对于非volatile变量之间,以及volatile以及非volatile变量之间的顺序,编译器还是会优化。

int a;volatile int b;int main(){    a = b + 1;    b = 0;}

   

       

__sync_synchronize

__sync_synchronize就是一种full barrier

当一个核心在Invalid状态进行写入时,首先会给其它CPU核发送Invalid消息,然后把当前写入的数据写入到Store
Buffer中。然后异步在某个时刻真正的写入到Cache
Line中。当前CPU核如果要读Cache Line中的数据,需要先扫描Store
Buffer之后再读取Cache Line(Store-Buffer
Forwarding)。但是此时其它CPU核是看不到当前核的Store
Buffer中的数据的,要等到Store Buffer中的数据被刷到了Cache
Line之后才会触发失效操作。

参考资料

Memory Ordering at Compile
Time

以下是我搭建的博客地址:
原文链接:http://itblogs.ga/blog/20150329150706/ 转载请注明出处

    

volatile的本意是“易变的”
     
由于访问寄存器的速度要快过RAM,所以编译器一般都会作减少存取外部RAM的优化。比如:
static int i=0;
int main(void)
{

while (1)
{
if (i) do_something();
}
}
/* Interrupt service routine. */
void ISR_2(void)
{
i=1;
}
   
程序的本意是希望ISR_2中断产生时,在main当中调用do_something函数,但是,由于编译器判断在main函数里面没有修改过i,因此可能只执行一次对从i到某寄存器的读操作,然后每次if判断都只使用这个寄存器里面的“i副本”,导致do_something永远也不会被调用。如果变量加上volatile修饰,则编译器保证对此变量的读写操作都不会被优化(肯定执行)。此例中i也应该如此说明。
    一般说来,volatile用在如下的几个地方:
1、中断服务程序中修改的供其它程序检测的变量需要加volatile;
2、多任务环境下各任务间共享的标志应该加volatile;
3、存储器映射的硬件寄存器通常也要加volatile说明,因为每次对它的读写都可能由不同意义;
另外,以上这几种情况经常还要同时考虑数据的完整性(相互关联的几个标志读了一半被打断了重写),在1中可以通过关中断来实现,2中可以禁止任务调度,3中则只能依靠硬件的良好设计了。
二、volatile 的含义
    
volatile总是与优化有关,编译器有一种技术叫做数据流分析,分析程序中的变量在哪里赋值、在哪里使用、在哪里失效,分析结果可以用于常量合并,常量传播等优化,进一步可以死代码消除。但有时这些优化不是程序所需要的,这时可以用volatile关键字禁止做这些优化,volatile的字面含义是易变的,它有下面的作用:
 1
不会在两个操作之间把volatile变量缓存在寄存器中。在多任务、中断、甚至setjmp环境下,变量可能被其他的程序改变,编译器自己无法知道,volatile就是告诉编译器这种情况。
2 不做常量合并、常量传播等优化,所以像下面的代码:
volatile int i = 1;
if (i > 0) …
if的条件不会当作无条件真。
3
对volatile变量的读写不会被优化掉。如果你对一个变量赋值但后面没用到,编译器常常可以省略那个赋值操作,然而对Memory
Mapped IO的处理是不能这样优化的。
   
前面有人说volatile可以保证对内存操作的原子性,这种说法不大准确,其一,x86需要LOCK前缀才能在SMP下保证原子性,其二,RISC根本不能对内存直接运算,要保证原子性得用别的方法,如atomic_inc。
   
对于jiffies,它已经声明为volatile变量,我认为直接用jiffies++就可以了,没必要用那种复杂的形式,因为那样也不能保证原子性。
    你可能不知道在Pentium及后续CPU中,下面两组指令
inc jiffies
;;
mov jiffies, %eax
inc %eax
mov %eax, jiffies
作用相同,但一条指令反而不如三条指令快。
三、编译器优化 → C关键字volatile → memory破坏描述符zz
   
“memory”比较特殊,可能是内嵌汇编中最难懂部分。为解释清楚它,先介绍一下编译器的优化知识,再看C关键字volatile。最后去看该描述符。
1、编译器优化介绍
    
内存访问速度远不及CPU处理速度,为提高机器整体性能,在硬件上引入硬件高速缓存Cache,加速对内存的访问。另外在现代CPU中指令的执行并不一定严格按照顺序执行,没有相关性的指令可以乱序执行,以充分利用CPU的指令流水线,提高执行速度。以上是硬件级别的优化。再看软件一级的优化:一种是在编写代码时由程序员优化,另一种是由编译器进行优化。编译器优化常用的方法有:将内存变量缓存到寄存器;调整指令顺序充分利用CPU指令流水线,常见的是重新排序读写指令。对常规内存进行优化的时候,这些优化是透明的,而且效率很好。由编译器优化或者硬件重新排序引起的问题的解决办法是在从硬件(或者其他处理器)的角度看必须以特定顺序执行的操作之间设置内存屏障(memory
barrier),linux 提供了一个宏解决编译器的执行顺序问题。
void Barrier(void)
    
这个函数通知编译器插入一个内存屏障,但对硬件无效,编译后的代码会把当前CPU寄存器中的所有修改过的数值存入内存,需要这些数据的时候再重新从内存中读出。
2、C语言关键字volatile
    
C语言关键字volatile(注意它是用来修饰变量而不是上面介绍的__volatile__)表明某个变量的值可能在外部被改变,因此对这些变量的存取不能缓存到寄存器,每次使用时需要重新存取。该关键字在多线程环境下经常使用,因为在编写多线程的程序时,同一个变量可能被多个线程修改,而程序通过该变量同步各个线程,例如:
DWORD __stdcall threadFunc(LPVOID signal)
{
int* intSignal=reinterpret_cast<int*>(signal);
*intSignal=2;
while(*intSignal!=1)
sleep(1000);
return 0;
}
     该线程启动时将intSignal 置为2,然后循环等待直到intSignal 为1
时退出。显然intSignal的值必须在外部被改变,否则该线程不会退出。但是实际运行的时候该线程却不会退出,即使在外部将它的值改为1,看一下对应的伪汇编代码就明白了:
mov ax,signal
label:
if(ax!=1)
goto label
    
对于C编译器来说,它并不知道这个值会被其他线程修改。自然就把它cache在寄存器里面。记住,C
编译器是没有线程概念的!这时候就需要用到volatile。volatile
的本意是指:这个值可能会在当前线程外部被改变。也就是说,我们要在threadFunc中的intSignal前面加上volatile关键字,这时候,编译器知道该变量的值会在外部改变,因此每次访问该变量时会重新读取,所作的循环变为如下面伪码所示:
label:
mov ax,signal
if(ax!=1)
goto label
3、Memory
     
有了上面的知识就不难理解Memory修改描述符了,Memory描述符告知GCC:
1)不要将该段内嵌汇编指令与前面的指令重新排序;也就是在执行内嵌汇编代码之前,它前面的指令都执行完毕
2)不要将变量缓存到寄存器,因为这段代码可能会用到内存变量,而这些内存变量会以不可预知的方式发生改变,因此GCC插入必要的代码先将缓存到寄存器的变量值写回内存,如果后面又访问这些变量,需要重新访问内存。
     如果汇编指令修改了内存,但是GCC
本身却察觉不到,因为在输出部分没有描述,此时就需要在修改描述部分增加“memory”,告诉GCC
内存已经被修改,GCC
得知这个信息后,就会在这段指令之前,插入必要的指令将前面因为优化Cache
到寄存器中的变量值先写回内存,如果以后又要使用这些变量再重新读取。
    
使用“volatile”也可以达到这个目的,但是我们在每个变量前增加该关键字,不如使用“memory”方便。

__thread

__threadgcc内置的用于多线程编程的基础设施。用__thread修饰的变量,每个线程都拥有一份实体,相互独立,互不干扰。举个例子:

#include<iostream>  
#include<pthread.h>  
#include<unistd.h>  
using namespace std;
__thread int i = 1;
void* thread1(void* arg);
void* thread2(void* arg);
int main()
{
  pthread_t pthread1;
  pthread_t pthread2;
  pthread_create(&pthread1, NULL, thread1, NULL);
  pthread_create(&pthread2, NULL, thread2, NULL);
  pthread_join(pthread1, NULL);
  pthread_join(pthread2, NULL);
  return 0;
}
void* thread1(void* arg)
{
  cout<<++i<<endl;//输出 2  
  return NULL;
}
void* thread2(void* arg)
{
  sleep(1); //等待thread1完成更新
  cout<<++i<<endl;//输出 2,而不是3
  return NULL;
}

需要注意的是:

1,__thread可以修饰全局变量、函数的静态变量,但是无法修饰函数的局部变量。

2,被__thread修饰的变量只能在编译期初始化,且只能通过常量表达式来初始化。

责任编辑:

以下是我搭建的博客地址:
http://itblogs.ga/blog/20150329150706/    欢迎到这里阅读文章。

  • class=”wp_keywordlink”>Volatile
  • __thread
  • Memory Barrier
  • __sync_synchronize
  • 变量写入操作不依赖变量当前值,或确保只有一个线程更新变量的值(Java可以,C++仍然不能)
  • 该变量不会与其他变量一起纳入
  • 变量并未被锁保护

本文简单介绍volatile关键字的使用,进而引出编译期间内存乱序的问题,并介绍了有效防止编译器内存乱序所带来的问题的解决方法,文中简单提了下CPU指令乱序的现象,但并没有深入讨论。
    

Java 使用volatile或atomic

volatile关键字

volatile关键字用来修饰一个变量,提示编译器这个变量的值随时会改变。通常会在多线程、信号处理、中断处理、读取硬件寄存器等场合使用。

程序在执行时,通常将数据(变量的值)从内存的读到寄存器中,然后进行运算,此后对该变量的处理,都是直接访问寄存器就可以了,不再访问内存,因为
访存的代价是很高的(这块是访问寄存器还是重新访存加载到寄存器是编译器在编译阶段就决定了的)。但在上述说的几种情况下,内存会被另一个线程或者信号处
理函数、中断处理函数、硬件改掉,这样,代码只访问寄存器的话,永远得不到真实的值。

   

对这样的变量(会在多线程、线程与信号、线程与中断处理中共同访问的,或者硬件寄存器),在定义时都会加上volatile关键字修饰。这样编译器
在编译时,编译出的指令会重新访存,这样就能保证拿到正确的数据了。但这里需要注意的是,编译器只能做到让指令重新访问内存,而不是直接使用寄存器中的
值,这些和缓存没有关系,具体执行时指令是访问内存还是访问的缓存,编译器也无法干预。

   

另外,除了使用寄存器来避免多次访存外,编译器有时可能直接将变量全部优化掉,使用常数代替。比如:

int main()
{
    int a = 1;
    int b = 2;

    printf(“a = %d, b = %d \n”, a, b);
}

   

编译器可能直接优化为:     

int main()
{
    printf(“a = %d, b = %d \n”, 1, 2);
}

   

  如果对ab的声明加了 volatile关键字,编译器将不在做这样的优化。

             

还有,对所有volatile变量,编译器在编译阶段保证不会将访问volatile变量的指令进行乱序重排。

    

   

2.2 happens-before规则

voldatile关键字首先具有“易变性”,声明为volatile变量编译器会强制要求读内存,相关语句不会直接使用上一条语句对应的的寄存器内容,而是重新从内存中读取。

GCC
4以后的版本也提供了Built-in的屏障函数__sync_synchronize(),这个屏障函数既是编译屏障又是内存屏障,代码插入这个函数的地方会被安插一条mfence指令。

C++11相应定义了6种内存模型:

Intel为此提供三种内存屏障指令:

  • std::memory_order_seq_cst 所有读写操作不能跨过,写顺序全线程可见
  • std::memory_order_acq_rel
    所有读写操作不能跨过,写顺序仅同步线程间可见、std::memory_order_release
    所有读写操作不能往后乱序、std::memory_order_acquire
    所有读写操作不能向前乱序、std::memory_order_consume
    依赖该读操作的后续读写操作不能向前乱序
  • std::memory_order_relaxed 无特殊要求

一. 内存屏障 Memory Barrior

X86-64下仅支持一种指令重排:Store-Load
,即读操作可能会重排到写操作前面,同时不同线程的写操作并没有保证全局序,例子见《Intel®
64 and IA-32 Architectures Software Developer’s
Manual》手册8.6.1、8.2.3.7节。要注意的是这个问题只能用mfence解决,不能靠组合lfence和sfence解决。

X86-64一般情况根本不会需要使用lfence与sfence这两个指令,除非操作Write-Through内存或使用
non-temporal 指令(NT指令,属于SSE指令集),比如movntdq, movnti,
maskmovq,这些指令也使用Write-Through内存策略,通常使用在图形学或视频处理,Linux编程里就需要使用GNC提供的专门的函数(例子见参考资料13:Memory
part 5: What programmers can do)。

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注