- C++11 FAQ 中文版 - C++11 FAQ
- Stroustrup 先生关于中文版的授权许可邮件
- Stroustrup 先生关于 C++11 FAQ 的一些说明
- 关于 C++11 的一般性的问题
- 您是如何看待 C++11 的?
- 什么时候 C++0x 会成为一部正式的标准呢?
- 编译器何时将会实现 C++11 标准呢?
- 我们何时可以用到新的标准库文件?
- C++0x 将提供何种新的语言特性呢?
- C++11 会提供哪些新的标准库文件呢?
- C++0x 努力要达到的目标有哪些?
- 指导标准委员会的具体设计目标是什么?
- 在哪里可以找到标准委员会的报告?
- 从哪里可以获得有关 C++11 的学术性和技术性的参考资料?
- 还有哪些地方我可以读到关于 C++0x 的资料?
- 有关于 C++11 的视频吗?
- C++0x 难学吗?
- 标准委员会是如何运行的?
- 谁在标准委员会里?
- 实现者应以什么顺序提供 C++11 特性?
- 将会是 C++1x 吗?
- 标准中的"concepts"怎么了?
- 有你不喜欢的 C++特性吗?
- 关于独立的语言特性的问题
- __cplusplus 宏
- alignment(对齐方式)
- 属性(Attributes)
- atomic_operations
- auto – 从初始化中推断数据类型
- C99 功能特性
- 枚举类——具有类域和强类型的枚举
- carries_dependency
- 复制和重新抛出异常
- 常量表达式(constexpr)
- decltype – 推断表达式的数据类型
- 控制默认函数——默认或者禁用
- 控制默认函数——移动(move) 或者复制(copy)
- 委托构造函数(Delegating constructors)
- 并发性动态初始化和析构
- noexcept – 阻止异常的传播与扩散
- 显式转换操作符
- 扩展整型
- 外部模板声明
- 序列 for 循环语句
- 返回值类型后置语法
- 类成员的内部初始化
- 继承的构造函数
- 初始化列表
- 内联命名空间
- Lambda 表达式
- 用作模板参数的局部类型
- long long(长长整数类型)
- 内存模型
- 预防窄转换
- nullptr——空指针标识
- 对重载(override) 的控制: override
- 对重载(override) 的控制:final
- POD
- 原生字符串标识
- 右角括号
- 右值引用
- Simple SFINAE rule
- 静态(编译期)断言 — static_assert
- 模板别名(正式的名称为"template typedef")
- 线程本地化存储 (thread_local)
- unicode 字符
- 统一初始化的语法和语义
- (广义的)联合体
- 用户定义数据标识(User-defined literals)
- 可变参数模板(Variadic Templates)
- 关于标准库的问题
- abandoning_a_process
- 算法方面的改进
- array
- async()
- atomic_operations
- 条件变量(Condition variables)
- 标准库中容器方面的改进
- std::function 和 std::bind
- std::forward_list
- std::future 和 std::promise
- 垃圾回收(应用程序二进制接口)
- 无序容器(unordered containers)
- 锁(locks)
- metaprogramming(元编程)and type traits
- 互斥
- 随机数的产生
- 正则表达式(regular expressions)
- 具有作用域的内存分配器
- 共享资源的智能指针——shared_ptr
- smart pointers
- 线程(thread)
- 时间工具程序
- 标准库中的元组(std::tuple)
- unique_ptr
- weak_ptr
- system error
内存模型
(译注:这一个 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 .
N2556==08-0066.
- Hans-J. Boehm:
HPL technical report 2009-259.
“what every programmer should know about memory model issues.”
- Hans-J. Boehm and Paul McKenney:
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论