# 内存模型 （译注：这一个item有相当深的理论深度，原文也比较晦涩难懂，翻译者提醒大家，最好参照原文理解，如果翻译中有什么不恰当的地方，还请批评指出，不胜感谢。） 所谓“内存模型”，是计算机（硬件）体系结构与编译器双方之间的一种约定。有了它，大多数程序员便不用处处考虑日新月异的计算机硬件细节。如果没有内存模型，那么线程机制、锁机制及无锁编程等都无从谈起。 内存模型的最关键保证是：两个线程可以各自独立地存取各自的“内存位置”而不会互相影响。那么，什么是“内存位置”呢？ 一个内存位置要么是一个标量类型的对象，要么是一个连续且位宽非零的最长比特域组。例如：此处的S具有四个独立的内存位置： ``` struct S {<br /> char a; // 位置#1 int b:5, // 位置#2 int c:11, // 注意：":0"是一个“特殊符号” //（译注：此处的":0"会将一个int对象分割为两个内存位置， // 因为上面所讲的内存位置的第二种情况需要“连续且位宽非零”） int :0, int d :8; // 位置#3 struct {int ee:8; } e; // 位置#4 }; ``` 内存模型为什么如此重要？为什么它不是显而易见的？(译注：此处指“为什么应用程序所使用的内存模型与计算机的物理内存结构不是直接一致的，即不用经过任何中间层”，在本例中，应当指为什么b和c属于同一个内存位置)。 难道并非一直如此吗？ 问题在于，如果多个计算任务真正地并发运行，那么当这些来自不同计算任务中不相关（很明显）的指令代码在同一时刻执行时，内存硬件的诡异行为将会被暴露无遗（译注：一个诡异行为就是，在上述例子中，对变量b,c,d的存取，并非一次仅操作5,11或者8个bit。具体操作与处理器的行为有关）。事实上，如果没有了编译器的支持，指令流/数据流以及缓存命中等细节问题将会被直接暴露给应用程序开发人员，而他们对此毫无对策。即使两个线程之间不存在数据共享，情况依然糟糕如此！考虑如下两个分开编译的“线程”： ``` //线程 1: char c; c = 1; int x = c; //线程 2 char b; b = 1; int y = b; ``` 为了尽量模拟现实状态，我使用了分开编译（对每个线程）来保证编译器/优化器不会对内存进行优化（译注：此处指对每个线程内的代码进行逐行编译，然后连接，以避免代码优化），以防止“聪明”的编译器跳过读取变量c和b而直接将x和y初始化为1。那么现在，x和y的值可能是什么呢？按照C++11的标准，唯一正确的答案，也是显而易见的那个，x和y均为1。但如果你采用了一个传统意义上的优秀的带预并发处理(pre-concurrency)的C或者C++编译器，那么事情变得有趣起来：x和y的可能值会是0和0(很少发生)，或者1和0，或者0 和1，或者1和1。这些都是在“真实环境”下观察到的情况。为何如此呢？原因在于，链接器可能会将变量c和b的位置分配在相邻的内存上（在同一个word内），而且90年代的C/C++标准并未对此作出禁令（译注：指不拒绝这种变量在内存中的存储位置安排方式）。在这种情况下，C++就如同所有那些未考虑实际硬件并发就进行设计的语言一样，由于现代CPU无法读写单个的字节，读写操作在处理中总是以word为单位进行的，所以，对变量c的赋值实际上是“读取包含变量c的一个word，替换掉其中的c部分，然后再写回这个word”。由于对变量b的赋值也是如此进行的，这就造成了两个操作变量b和变量c的线程有如此多地机会互相干涉、影响（译注：线程1操作变量c时，回写操作会改变变量b的值，线程2也是如此，这就造成了两个线程之间的干扰，而b和c也处于不稳定状态），即使它们之间并未共享数据（由它们的源代码来看，的确如此）。 因此，C++11保证了在“独立的内存位置”上，肯定不会发生如上这种问题。或者换种说法：“对于同一内存位置，多个线程同时访问时需要加锁，除非所有的访问都是只读”。需要留意的是，一个单word内的不同比特域并非属于独立的内存位置（译注：即它们总是被一起读取和写入的），所以不要轻易在线程之间共享带有比特域的结构，除非使用锁机制来消除潜在风险。除过这个需要特别注意的地方外，C++的内存模型就如同“大家所期待的那样”，简单而且纯洁) （译注：指对象结构的内存模型就按照结构中的声明顺序进行排列，而且不会发生干扰问题）。 但是，对于底层的并行计算问题，要想直接地进行考虑，并不总是那么简单。考虑下面的代码： ``` // 开始的时候， x==0 ，y==0 if (x) y = 1; // 线程 1 if (y) x = 1; // 线程 2 ``` 这里有没有问题呢？或者更直接地说，这里会不会发生资源竞争呢？（答案是：不会发生） （译注：此处范例的详细解释请翻阅参考资料之“Hans-J. Boehm:Threads basics”） 幸运的是，我们赶上了好时代，每一个现代C++编译器（我所知道的）都给予上面问题正确的答案，而且它们这些年来也是如此做的。毕竟，长期以来C++一直担任着开发并发系统中关键部分的重任，相应的语言标准总不能停滞不前吧。 参考： * Standard: 1.7 The C++ memory model [intro.memory] * Paul E. McKenney, Hans-J. Boehm, and Lawrence Crowl: [C++ Data-Dependency Ordering: Atomics and Memory Model](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2556.html). N2556==08-0066. * Hans-J. Boehm: [Threads basics](http://www.hpl.hp.com/techreports/2009/HPL-2009-259html.html), HPL technical report 2009-259. “what every programmer should know about memory model issues.” * Hans-J. Boehm and Paul McKenney: [A slightly dated FAQ on C++ memory model issues](http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/user-faq.html).