1-4章
初始的C++标准在1998年发布，13年后，C++标准委员会给语言本身，以及标准库，带来了一次重大的变革。
新C++标准（也被称为C++11或C++0x）在2011年发布，带来一系列的变革让C++编程更加简单和高效。
C++标准第一次承认多线程在语言中的存在，并在标准库中为多线程提供组件。这意味着使用C++编写与平台无关的多线程程序成为可能，也为可移植性提供了强有力的保证
读者们，有两个问题可以先问一下自己：
1）什么要使用并发？
2）什么情况下不能使用并发？
多进程并发：在类似于Erlang的编程环境中，将进程作为并发的基本构造块。
C++标准并未对进程间通信提供任何原生支持，所以使用多进程的方式实现，这会依赖与平台相关的API。因此，本书只关注使用多线程的并发，并且在此之后所提到“并发”，均假设为多线程来实现。
回答上面的问题：
1）什么要使用并发？
主要原因有两个：关注点分离(SOC)和性能。事实上，它们应该是使用并发的唯一原因；如果你观察得足够仔细，所有因素都可以归结到其中的一个原因。
2）什么情况下不能使用并发？
知道何时不使用并发与知道何时使用它一样重要。基本上，不使用并发的唯一原因就是，收益比不上成本。使用并发的代码在很多情况下难以理解，因此编写和维护的多线程代码就会产生直接的脑力成本，同时额外的复杂性也可能引起更多的错误。除非潜在的性能增益足够大或关注点分离地足够清晰，能抵消所需的额外的开发时间以及与维护多线程代码相关的额外成本(代码正确的前提下)；否则，别用并发。
同样地，性能增益可能会小于预期；因为操作系统需要分配内核相关资源和堆栈空间，所以在启动线程时存在固有的开销，然后才能把新线程加入调度器中，所有这一切都需要时间。如果在线程上的任务完成得很快，那么任务实际执行的时间要比启动线程的时间小很多，这就会导致应用程序的整体性能还不如直接使用“产生线程”的方式。
此外，线程是有限的资源。如果让太多的线程同时运行，则会消耗很多操作系统资源，从而使得操作系统整体上运行得更加缓慢。不仅如此，因为每个线程都需要一个独立的堆栈空间，所以运行太多的线程也会耗尽进程的可用内存或地址空间。对于一个可用地址空间为4GB(32bit)的平坦架构的进程来说，这的确是个问题：如果每个线程都有一个1MB的堆栈(很多系统都会这样分配)，那么4096个线程将会用尽所有地址空间，不会给代码、静态数据或者堆数据留有任何空间。即便64位(或者更大)的系统不存在这种直接的地址空间限制，但其他资源有限：如果你运行了太多的线程，最终也是出会问题的。尽管线程池(参见第9章)可以用来限制线程的数量，但这也并不是什么灵丹妙药，它也有自己的问题。
当客户端/服务器(C/S)应用在服务器端为每一个链接启动一个独立的线程，对于少量的链接是可以正常工作的，但当同样的技术用于需要处理大量链接的高需求服务器时，也会因为线程太多而耗尽系统资源。在这种场景下，使用线程池可以对性能产生优化（参见第9章）。
最后，运行越多的线程，操作系统就需要做越多的上下文切换，每一次切换都需要耗费本可以花在有价值工作上的时间。所以在某些时候，增加一个额外的线程实际上会降低，而非提高应用程序的整体性能。为此，如果你试图得到系统的最佳性能，可以考虑使用硬件并发(或不用)，并调整运行线程的数量。
为性能而使用并发就像所有其他优化策略一样:它拥有大幅度提高应用性能的潜力，但它也可能使代码复杂化，使其更难理解，并更容易出错。因此，只有应用中具有显著增益潜力的性能关键部分，才值得并发化。当然，如果性能收益的潜力仅次于设计清晰或关注点分离，可能也值得使用多线程设计。
C++多线程历史
C++98(1998)标准不承认线程的存在，并且各种语言要素的操作效果都以顺序抽象机的形式编写。不仅如此，内存模型也没有正式定义，所以在C++98标准下，没办法在缺少编译器相关扩展的情况下编写多线程应用程序。
当然，编译器供应商可以自由地向语言添加扩展，添加C语言中流行的多线程API———POSIX标准中的C标准和Microsoft Windows API中的那些———这就使得很多C++编译器供应商通过各种平台相关扩展来支持多线程。这种编译器支持一般受限于只能使用平台相关的C语言API，并且该C++运行库(例如,异常处理机制的代码)能在多线程情况下正常工作。因为编译器和处理器的实际表现很不错了，所以在少数编译器供应商提供正式的多线程感知内存模型之前，程序员们已经编写了大量的C++多线程程序了。
由于不满足于使用平台相关的C语言API来处理多线程，C++程序员们希望使用的类库能提供面向对象的多线程工具。像MFC这样的应用框架，如同Boost和ACE这样的已积累了多组类的通用C++类库，这些类封装了底层的平台相关API，并提供用来简化任务的高级多线程工具。各种类和库在细节方面差异很大，但在启动新线程的方面，总体构造却大同小异。一个为许多C++类和库共有的设计，同时也是为程序员提供很大便利的设计，也就是使用带锁的获取资源即初始化(RAII, Resource Acquisition Is Initialization)的习惯，来确保当退出相关作用域时互斥元解锁。
C++11支持并发
只有在C++11标准下，才能编写不依赖平台扩展的多线程代码。
新标准中不仅有了一个全新的线程感知内存模型，C++标准库也扩展了：包含了用于管理线程(参见第2章)、保护共享数据(参见第3章)、线程间同步操作(参见第4章)，以及低级原子操作(参见第5章)的各种类。
新的C++标准直接支持原子操作，允许程序员通过定义语义的方式编写高效的代码，从而无需了解与平台相关的汇编指令。这对于试图编写高效、可移植代码的程序员们来说是一个好消息；编译器不仅可以搞定具体平台，还可以编写优化器来解释操作语义，从而让程序整体得到更好的优化。
虽然C++线程库为多线程和并发处理提供了较全面的工具，但在某些平台上提供额外的工具。为了方便地访问那些工具的同时，又使用标准C++线程库，在C++线程库中提供一个native_handle()成员函数，允许通过使用平台相关API直接操作底层实现。就其本质而言，任何使用native_handle()执行的操作都是完全依赖于平台的，这超出了本书(同时也是标准C++库本身)的范围。
线程启动
使用C++线程库启动线程，可以归结为构造std::thread对象：
等待线程完成
只能对一个线程使用一次join();一旦已经使用过join()，std::thread对象就不能再次加入了，当对其使用joinable()时，将返回false。但是, 也有一个例外, 就是当除了第一个参数以外的其他参数都有默认值的时候, explicit关键字依然有效, 此时, 当调用构造函数时只传入一个参数, 等效于只有一个参数的类构造函数。
向线程函数传递参数
期望传递一个引用，但整个对象被复制了。当线程更新一个引用传递的数据结构时，这种情况就可能发生，比如：
void update_data_for_widget(widget_id w,widget_data& data); // 1
void oops_again(widget_id w)
{
widget_data data;
std::thread t(update_data_for_widget,w,data); // 2
display_status();
t.join();
process_widget_data(data); // 3
}
虽然update_data_for_widget①的第二个参数期待传入一个引用，但是std::thread的构造函数②并不知晓；构造函数无视函数期待的参数类型，并盲目的拷贝已提供的变量。当线程调用update_data_for_widget函数时，传递给函数的参数是data变量内部拷贝的引用，而非数据本身的引用。因此，当线程结束时，内部拷贝数据将会在数据更新阶段被销毁，且process_widget_data将会接收到没有修改的data变量③。对于熟悉std::bind的开发者来说，问题的解决办法是显而易见的：可以使用std::ref将参数转换成引用的形式，从而可将线程的调用改为以下形式：
std::thread t(update_data_for_widget,w,std::ref(data));
如果你熟悉std::bind，就应该不会对以上述传参的形式感到奇怪，因为std::thread构造函数和std::bind的操作都在标准库中定义好了，可以传递一个成员函数指针作为线程函数，并提供一个合适的对象指针作为第一个参数：
class X
{
public:
void do_lengthy_work();
};
X my_x;
std::thread t(&X::do_lengthy_work,&my_x); // 1
这段代码中，新线程将my_x.do_lengthy_work()作为线程函数；my_x的地址①作为指针对象提供给函数。也可以为成员函数提供参数：std::thread构造函数的第三个参数就是成员函数的第一个参数，以此类推(代码如下，译者自加)。
class X
{
public:
void do_lengthy_work(int);
};
X my_x;
int num(0);
std::thread t(&X::do_lengthy_work, &my_x, num);
有趣的是，提供的参数可以移动，但不能拷贝。"移动"是指:原始对象中的数据转移给另一对象，而转移的这些数据就不再在原始对象中保存了(译者：比较像在文本编辑的"剪切"操作)。std::unique_ptr就是这样一种类型(译者：C++11中的智能指针)，这种类型为动态分配的对象提供内存自动管理机制(译者：类似垃圾回收)。同一时间内，只允许一个std::unique_ptr实现指向一个给定对象，并且当这个实现销毁时，指向的对象也将被删除。移动构造函数(move constructor)和移动赋值操作符(move assignment operator)允许一个对象在多个std::unique_ptr实现中传递(有关"移动"的更多内容，请参考附录A的A.1.1节)。使用"移动"转移原对象后，就会留下一个空指针(NULL)。移动操作可以将对象转换成可接受的类型，例如:函数参数或函数返回的类型。当原对象是一个临时变量时，自动进行移动操作，但当原对象是一个命名变量，那么转移的时候就需要使用std::move()进行显示移动。下面的代码展示了std::move的用法，展示了std::move是如何转移一个动态对象到一个线程中去的：
void process_big_object(std::unique_ptr<big_object>);
std::unique_ptr<big_object> p(new big_object);
p->prepare_data(42);
std::thread t(process_big_object,std::move(p));
std::thread实例不像std::unique_ptr那样能占有一个动态对象的所有权，但是它能占有其他资源：每个实例都负责管理一个执行线程。执行线程的所有权可以在多个std::thread实例中互相转移，这是依赖于std::thread实例的可移动且不可复制性。不可复制保性证了在同一时间点，一个std::thread实例只能关联一个执行线程；可移动性使得程序员可以自己决定，哪个实例拥有实际执行线程的所有权。
转移线程所有权