C++多线程模型与锁

C++内存模型

看到《C++0x漫谈》系列之：多线程内存模型之前，哪里会想到一个多线程可以搞得这么复杂，各种例子看过之后感觉三观尽毁……程序员没错，都是编译器优化惹的祸。当然，编译器也是合乎之前的标准，问题在哪里？规定多线程安全的标准相对缺失。那具体来讲到底缺失的标准具体是什么呢？上面的文章最后只讲了“顺序一致性”，并没有给出详细的技术上的答案。而且，我还是有一个疑惑，如果上文中所说的pthread库等都无法保证多线程程序的正确性，那么多人用没出问题？没人反应？那Windows/Linux上的C++多线程程序都是怎么写的？

接着，又看到了《程序员的自我修养》中关于加锁不能保证线程安全的一个错误这篇文章。从文章和下面跟帖留言的讨论可以看出：pthread库是有自己的一套内存可见性的规范，所以保证了程序的正常执行。而如果使用的锁机制没有保证这一点，就可能存在所说的加锁也不能保证线程安全的问题。但刘未鹏文中那个pthread的例子应该也不是假的，这是咱造纸太浅，没看懂～

到了C++11具体的内存模型，参见C++11 并发指南七(C++11 内存模型一：介绍)

我们必须对编译器和 CPU 作出一定的约束才能合理正确地优化你的程序，那么这个约束是什么呢？答曰：内存模型。C++程序员要想写出高性能的多线程程序必须理解内存模型，编译器会给你的程序做优化(静态)，CPU为了提升性能也有乱序执行(动态)，总之，程序在最终执行时并不会按照你之前的原始代码顺序来执行，因此内存模型是程序员、编译器，CPU 之间的契约，遵守契约后大家就各自做优化，从而尽可能提高程序的性能。C++11 中规定了 6 种访存次序(Memory Order)

但是具体的六种Memory Order怎样使用，区别感觉还是没讲清楚，关键是没有例子，等着看到了好的文章再补充~

———————————————看了多篇相关文章之后的分割线———————————————————
感觉这玩意儿真不是普通程序猿玩的啊～
参考如下：
c++11 内存模型解读——简单清楚。其中最后一段的几句话摘录如下：

内存模型方面的知识是很难理解，更难以正确使用的，在大多数情况下使用它而得到的些少性能优势，已经完全不值得为此而带来的代码复杂性及可读性方面的损失，如果你还在犹豫是否要用这些相对底层的东西的时候，就不要用它，犹豫就说明还有其它选择，不到没得选择，都不要亲自实现 lock free 相关的东西。

漫谈C++11多线程内存模型——文中讲了“happens-before”概念，但看了图和例子还是没看懂～哎，还是智商不够啊～
浅析C++多线程内存模型——文章很好，讲的较为详细了。而且他的博客上并行编程系列文章都很好值得一读。
C++11并发内存模型学习——文章中讲了consume，而且介绍了memory_order的几种类型。

信号量与自旋锁

看了陈皓的相关博客无锁队列的实现之后，感觉使用CAS啥的高大上。但是看代码心中不免有些疑惑——自旋操作都是while循环——这是在空耗CPU啊，能高效么？这前几天看到C++11已经支持，所以自己写了个程序看看到底有多高效。于是用Xcode写了个demo对比atomic_flag和mutex对比测试。100个线程，每个线程循环累加全局变量10000次。使用了自旋锁执行时间比使用mutex多很多，CPU使用率非常高，而mutex的CPU基本使用率很低。而Pthreads并行编程之spin lock与mutex性能对比分析这篇文章，测试并解释了上述现象，提出了自旋锁和mutex的使用场景：

pthread_spin_lock应该与kernel里面的spin lock一样，锁定的关键区域要比较小才可以。 如果一个线程1获得spin后，另一个线程2在另一个CPU busy-wait该spin lock过程， 如果线程2在跑完此次CPU时间后，仍未获得该spin lock，刚说明，线程1锁的时间太长了。 应该使用mutex，而不应该使用spin lock.

其他参考文章

活锁的概念
阿姆达尔法则（Amdahl’s Law）：总体执行时间T = S + P/N
读写锁的解释
一个加锁操作一般需要100个CPU时钟周期 Doug Lea提到java.util.concurrent库中一个Non Blocking的算法的实现大概需要1个人年，总共约500行代码。

——并行编程中的“锁”难题

多线程程序中操作的原子性 ——汇编还是很重要的，尤其是底层相关性较大的领域；此文还介绍了memory location的概念。