浅谈Volatile与多线程

标题:浅谈Volatile与多线程

2011-04-19 22:49:17

最近看的比较杂,摘了一些人的笔记!
随着多核的日益普及,越来越多的程序将通过多线程并行化的方式来提升性能。然而,编写正确的多线程程序一直是一件非常困的事情,volatile关键字的使用就是其中一个典型的例子。

C/C++中的volatile一般不能用于多线程同步

在C/C++中,如果想把一个变量声明为volatile,就相当于告诉编译器这个变量是“易变的”,他随时可能在其他地方被修改,所以编译器不能对其做任何变化:即每次读写该变量时都必须对其内存地址直接进行操作,并且所以对该变量的操作都必须严格按照程序中规定的顺序执行。举例来说,编译器的常常做的一种性能优化就是把需频繁读取的变量缓存到寄存器中,以提升访问速度。但如果该变量的值随时可能在片外被改变的话,那么就有可能出现被缓存的值并不是该变量的最新值情况,从而出现运行错误。在这种情况就需要用volatile关键字来修饰这个变量,以确保编译器不会对该变量读写操作进行任何缓存优化。另一个例子就是内存映射I/O操作。如下代码所示:

Int *p = get_io_address();

Int a, b;

A = *p;

B = *p;

P是一个指向硬件I/O端口的指针,该端口的值在每进行一次读操作后都会变化。这个程序连续对该端口进行两次读取操作已将两个不同的值分别赋值给a和b。如果不把a和b声明为volatile的话,编译器可能会”自作聪明”地认为两次从p读取的值都是一样的,从而把*b=*p优化成b = a,最终导致程序出错。

虽然C/C++中volatile关键字对这种“易变“的读写操作能起到一定的保护,但他却并不适用于多线程程序中共享变量的同步操作。究其根源,就在于C/C++标准中并没有volatile赋予原子性和顺序性的语义。

原子性

下面举个例子说明原子性。i++这看似原子的语句其实有三个操作组成:将该值从内存地址读取到寄存器中,对寄存器中的值进行加1操作,最后再将新值写回内存中,正是因为i++并不是原子的,所以如果两个线程同时进行i++操作的话仍会产生数据竞跑,从而导致i的最终值不等于2.在这种情况下,C/C++中的volatile关键字根本无法对该操作的原子性提供任何保障。

Volatile int  i=0;

//线程1

I++;

//线程2

I++;

顺序性

不幸的是,现在C/C++标准中的volatile关键字对共享变量操作的顺序性也未提供任何保障。以本文中的dekker算法为例:当两个线程分别执行dekker1和dekker2函数时候,改程序通过对flag1/2和turn的读写来实现两个线程对临界区中共享变量gCounter的互斥访问。这个算法的关键就在于对flag1/2和turn的读写操作是在其写操作之后进行的,因此它能保证dekker1和dekker2中对gCounterde的操作时互斥的,相当于把gCounter++放到一个临界区中去了。Dekker算法如下所示:

Volatile int flag1 = 0;

Volatile int flag2 = 0;

Volatile int turn = 1;

Volatile int gCounter = 0;

Void dekker1()

{

Flag1 = 1;

Turn = 2;

While( (flag2 == 1) && ( turn == 2) ){}

//进入临界区

gCounter++;

flag1 = 0; //离开临界区

}

Void dekker2()

{

Flag2 = 1;

Turn = 2;

While( (flag1 == 1) && ( turn == 2) ){}

//进入临界区

gCounter++;

flag2 = 0; //离开临界区

}

尽管volatile规定编译器不能对同一变量的所有操作进行乱序优化,但它却不能阻止编译器对不同volatile变量间的操作进行乱序优化。例如,编译器可能把dekker1中的flag2读操作提到flag1和turn写操作之前,从而导致对临界区的互斥访问失效,最终gCounter++操作就会出现数据竞跑现象。事实上,即使编译器没有对这个程序做任何优化,volatile 关键字也不能阻止多核CPU对该程序的乱序优化。以常见的x86硬件来说,它可以对不同变量x,y的store x --àload y进行乱序优化,把load y操作提到store x操作之前。这样的话,dekker1中flag2的读操作还是有可能会被提到flag1和turn的写操作之前,最终导致错误的计算结果。

那为什么编译器和多核CPU会对多线程程序做这样的乱序优化呢?因为从单核的视角来看,flag1 和 flag2,turn的读写操作之间没有任何依赖关系的,使用编译器/CPU当然可以对他们进行乱序优化以隐藏一部分的内存访问延迟,从而更好的利用CPU里的流水线。换句话说,这样的优化虽从单线程的角度来讲没有错,但却违反了设计这个多线程算法时所期望的多线程语义。要是解决这个问题,我们需要解决这个问题,我们需要自己添加内存栅栏以显式保证顺序性,或者干脆去别去实现这样的算法,转而使用类似pthread_mutex_lock这样的加锁操作来实现互斥访问。

综合上述,由于现有的C/C++标准中并没有对volatile添加原子性和顺序性的语义,所以绝大部分C/C++程序中使用volatile来进行多线程同步的用法是错误的。其实,我们之所以想用volatile变量进行同步,无非是因为锁,条件变量等方式的开销太大,所以想有一种轻量级的,高效的同步机制。

时间: 2024-11-08 22:26:41

浅谈Volatile与多线程的相关文章

浅谈volatile

浅谈volatile 这篇文章我们主要了解一下几个问题 volatile的特性与指令重排序 DCL单例 volatile的实现,内存屏障 volatile的特性和指令重排序 首先volatile拥有可见性,这里就不过多解释了 然后另外一点是它能解决指令重排序. 那么问题来了什么是指令冲排序? 通俗的讲 cpu的速度至少比内存快100倍,为了提升效率,会打乱原来的执行顺序,比如先执行指令A,但是A执行的比较慢,那么这个时候可能会直接去执行指令B,B先执行完了,这样B指令可能就排在了A指令前面,但是

java多线程浅谈

经常看到,一个对象的synchronized方法被一个线程调用后,那么其他线程还能调用该线程的其他方法吗? 网上给出各种答案,其中一种是:不能. 但是,我们有没有自己动手去写一个简单的程序来验证一下?从这个问题浅谈一下我对java多线程的理解. 要理解java的多线程,首先的理解jvm. 参见http://blog.csdn.net/kyfg27_niujin/article/details/7942006

浅谈getaddrinfo函数的超时处理机制

在sockproxy上发现,getaddrinfo 解析域名相比ping对域名的解析,慢很多.我觉得ping用了gethostbyname解析域名.问题变为getaddrinfo解析域名,是否比 gethostbyname慢.写测试程序,分别用getaddrinfo和gethostbyname解析,发现getaddrinfo确实慢. strace跟踪发现,getaddrinfo和DNS服务器通信10次,gethostbyname和DNS服务器通信2次. gethostbyname是古老的域名解析

五 浅谈CPU 并行编程和 GPU 并行编程的区别

前言 CPU 的并行编程技术,也是高性能计算中的热点,也是今后要努力学习的方向.那么它和 GPU 并行编程有何区别呢? 本文将做出详细的对比,分析各自的特点,为将来深入学习 CPU 并行编程技术打下铺垫. 区别一:缓存管理方式的不同 GPU:缓存对程序员不透明,程序员可根据实际情况操纵大部分缓存 (也有一部分缓存是由硬件自行管理). CPU:缓存对程序员透明.应用程序员无法通过编程手段操纵缓存. 区别二:指令模型的不同 GPU:采用 SIMT - 单指令多线程模型,一条指令配备一组硬件,对应32

浅谈程序员该具备的自我修养

各行各业的工作者,都有其要求,那么作为程序员,我们又该具备哪些素养呢?博主在这里浅谈个人看法,如有不当之处,请大佬们指正. 一.知识储备 1.数学 或许在很多人看来,学计算机用不到什么数学,最多也就是一百以内的加减乘除,用在for循环.数组索引之类的上面.但其实不然,大部分人这样觉得是因为基本都工作在应用层,所以相对而言,用到的数学知识会比较少,也比较浅显. 而当从应用层更深地学习研究时,就需要一定的数学能力了. 2.计算机 1)操作系统 操作系统(OS)是配置在计算机硬件上的第一层软件.是对硬

浅谈对Java中ThreadLocal类的理解

首先要明确:ThreadLocal不是一个多线程类,或者应该叫做线程局部变量.这从ThreadLocal的JDK定义中就可以看到 public class ThreadLocal<T>extends Object 可以看出ThreadLocal只是一个普普通通的类,并没有继承自Thread或实现Runnable接口. 同时也可以看到ThreadLocal使用了泛型,这样他就可以操作几乎任何类型的数据了.下面说JDK API代码时具体再说. 对此类,看看JDK API中的部分描述: 该类提供了线

浅谈linux内核栈(基于3.16-rc4)

在3.16-rc4内核源码中,内核给每个进程分配的内核栈大小为8KB.这个内核栈被称为异常栈,在进程的内核空间运行时或者执行异常处理程序时,使用的都是异常栈,看下异常栈的代码(include/linux/sched.h): 1 union thread_union { 2 struct thread_info thread_info; 3 unsigned long stack[THREAD_SIZE/sizeof(long)]; 4 }; THREAD_SIZE值为8KB,因此内核为进程的异常

浅谈ThreadPool 线程池(引用)

出自:http://www.cnblogs.com/xugang/archive/2010/04/20/1716042.html 浅谈ThreadPool 线程池 相关概念: 线程池可以看做容纳线程的容器: 一个应用程序最多只能有一个线程池: ThreadPool静态类通过QueueUserWorkItem()方法将工作函数排入线程池: 每排入一个工作函数,就相当于请求创建一个线程: 线程池的作用: 线程池是为突然大量爆发的线程设计的,通过有限的几个固定线程为大量的操作服务,减少了创建和销毁线程

浅谈android架构设计

到目前为止,android开发在网络上或者社区上没有公认的或者统一的开发框架,好多框架都是基于对方法的封装.今天在这浅谈两年来对android开发的理解,主要是思想上的理解,希望对大家有帮助. 我认为android开发可以从两个方面去总结架构的设计,在这里对于实现只做陈述: 一,就是大多数人的设计思路,对方法的封装. 在这里我根据开发的习惯对工程进行包的设计: 1. http:网络请求方法封装.这里建议采用线程+Handler的模式,把Http 中get方法和post两种请求方式分开,对于正常的