线程安全 相关概念

实现线程同步的几种手段:

     二元信号量:
          一种最简单的锁,只有两种状态 占用和非占用 适合只能被一个线程独占访问的资源
     多元信号量(信号量):
          一种初始化为N的信号量 允许最多N个线程对资源进行同时访问
     互斥量:
          和二元信号量类似,但是它只能用于实现对某个资源的独立访问 即不可用于实现同步 因为哪个线程获取了互斥量 该线程就必须释放该互斥量 而信号量可以由其他线程释放 用以实现同步
     临界区:
          比互斥量更加严格的一种互斥手段,因为它只在本进程可见 而互斥量在所有进程中可见 其他与互斥量相同
     读写锁:
          有三种状态 自由 共享和独占  它们各自被线程访问的权限不同 用于灵活的满足那些读取次数多 写入次数少的资源访问控制 在线程获得访问权限后 可以修改其读写锁状态  获取方式分为共享方式和独占方式
          自由:     两种获取方式均可获取权限
          共享:    仅共享方式可获取权限
          独占      只能等待当前使用线程使用完毕 并且修改读写锁状态才可获取
     条件变量:
          同时注册一个事件,让线程等待某一个事件触发条件变量来唤醒等待线程 该事件在某时刻被另一个线程触发 一个条件变量可以同时被多个线程等待 当条件变量有效后 所有线程得以恢复执行
     

 可重入函数:
     一个函数可重入,是指这个函数还没有执行完成,由于外部因素或内部调用,又一次进入该函数进行 主要有两种情况
     1.多个线程同时执行这个函数
     2.函数直接或间接地调用自身
     一个函数被称为是可重入的。表面该函数被重入之后不会产生任何不良后果。这需要函数满足一下几个条件
  •    不使用任何(局部)静态或者全局的非const变量
  •    不返回任何(局部)静态或者全局的非const变量的指针
  •    仅依赖于调用方提供的参数
  •    不依赖任何单个资源的锁(mutex等)
   不调用任何不可重入的函数
 
     如果一个函数满足以上条件 那么它是可重入的 可以安全的在多线程环境中使用

编译器的过度优化与CPU动态调度:

     由于现代编译器的过度优化,使得有时候我们即使合理的使用了锁也不一定能保证线程安全
     eg1
     x = 0;
     thread1       thread2
     lock();       lock();
     x++;          x++
     unlock();     unlock();
     上面两个线程执行完之后,x的值可不一定为2
     想象如下操作流程
     1.thread1 读取x到寄存器A 此时[A]=0;
     2.thread1 修改x  x++  此时[A] = 1;
     3.thread1 延迟写回缓存 (编译器优化)
     4.thread2 读取x到寄存器B(注意,在thread2中 它并不知道x的值放在寄存器A中 不同线程有着不同的寄存器环境)此时[B] = 0;
     5.thread2 修改x x++ 此时[B] = 1;
     6.接下来thread1 thread无论以何种顺序写回,x得到最终值为1
     eg2
     x = y = 0;
     thread1        thread2
     x = 1;         y = 1;
     r1 = y;        r2 = x;
     这样看起来,无论怎么执行 r1和r2必定至少有一个为1 然而未必
     由于CPU的动态调度,使得CPU在执行指令时为了提高效率可能会交换指令的顺序。另外 在编译器优化的时候,可能为了效率而交换毫不相干的两条相邻指令 也就是说 可能最终执行序列如下
     x = y = 0;
     thread1      thread2
     r1 = y;       y = 1;
     x = 1;        r2 = x;
     最终我们将得到r1 = r2 = 0
     对于上面两个问题 我们可以用volatile关键字实现阻止编译器过度优化 它可以做到:
     1.阻止编译器为了提高速度将一个变量缓存到寄存器内而不写回
     2.阻止编译器调整操作volatile变量的指令序列
     可见volatile可以解决第一个问题,但是volatile却不能解决第二个问题,因为即使阻止了编译器的动态调度,也无法阻止CPU的动态调度 
     这可以通过 barrier指令
     #define barrier() _asm_volatile ("lwsync")  //这里barrier()实现分隔其两边的指令流 不允许越界交换指令
     x = y = 0;
     thread1        thread2
     x = 1;          y = 1;
     barrier()      barrier();
     r1 = y;        r2 = x;
 
 
 
 

线程安全是个非常棘手的问题。即使你合理的使用了锁(lock),依然可能不会产生预期的效果。
让我们来看看貌似合理的代码

复制代码代码如下:

X=0;
Thread 1                   Thread2
lock();  lock();
x++;    x++;
unlock();  unlock();

你会认为执行完这两个线程之后,X的一定值等于2?没错,因为lock()和unlock()的保护,x++的执行并不会被打断。(为什么++操作会被多线程给扰乱呢?原因就在于++操作在被编译成汇编之后对应到了多条汇编代码。)但是,编译器却可能因为自作聪明的优化,把x放到register里面(因为寄存器速度快嘛),也就是说当Thread1执行完x++之后,被Thread2打断,但是1这个值只保存到了寄存器x里,没有写入内存中的x变量里。随后Thread2执行完成后,内存中x的值等于1,此时,Thread1再执行完,内存中的x又被写入为1.
原来都是编译器倒得鬼!

 

再看一个例子

复制代码代码如下:

x=y=0;
Thread1                        Thread2
y=1;                                x=1;
r1=x;                               r2=y;

当你拍胸脯向崇拜你的MM保证说:r1或者r2至少有一个为1的时候,可惜编译器又再一次的站到了你的对立面。

 

原因是早在十几年前还是几十年前,编译器就有了这么一种优化机制,为了提高效率而交换指令的序列。所以上面的代码到了可能变成了这样:

复制代码代码如下:

x=y=0;
Thread1                        Thread2
r1=x;                             r2=y;
y=1;                              x=1;                

 

 


知道你错了吧~还好我们还有volatile:
1. 阻止编译器为了提高速度将变量缓存寄存到寄存器内而不写回内存。
2. 阻止编译器调整操作指令序列

 

哈哈,可惜道高一尺,魔高一丈。CPU动态调度的功能,CPU可以交换指令序列。volatile帮不了你,但宙斯大帝为我们发明了:barrier指令(这是一个CPU的指令)能够帮组我们阻止CPU调整操作指令序列。
好想目前我们解决了现场安全的问题了。

有一个著名的与换序有关的问题来至于Singleton模式的double-check。代码大概是这样子的:

复制代码代码如下:

volatile Singleton* Singleton::_instance = 0;

复制代码代码如下:

static Singleton& Instance() {
      if (0 == _instance) {
          Lock lock(_mutex);
          if (0 == _instance) {
              _instance = new Singleton();
              atexit(Destroy);
          }
      }
      return *_instance;
 }

简单的说,编译器为了效率可能会重排指令的执行顺序(compiler-based reorderings)。
看这一行代码:
_instance = new Singleton();

 

在编译器未优化的情况下顺序如下:
1.new operator分配适当的内存;
2.在分配的内存上构造Singleton对象;
3.内存地址赋值给_instance。

但是当编译器优化后执行顺序可能如下:
1.new operator分配适当的内存;
2.内存地址赋值给_instance;
3.在分配的内存上构造Singleton对象。

当编译器优化后,如果线程一执行到2后被挂起。线程二开始执行并发现0 == _instance为false,于是直接return,而这时Singleton对象可能还未构造完成,后果...

posted @ 2015-06-10 17:44  穆穆兔兔  阅读(284)  评论(0编辑  收藏  举报