在应用程序中使用并发的原因主要有两个：关注点分离和性能。事实上，我甚至可以说它们差不多是使用并发的唯一原因；当你观察得足够仔细时，一切其他因素都可以归结到这两者之一（或者可能是二者兼有，当然，除了像“我愿意”这样的原因之外）。
为了划分关注点而使用并发
在编写软件时，划分关注点总是个好主意。通过将相关的代码放在一起并将无关的代码分开，这种方法可以使你的程序更容易理解和测试，从而减少出错的可能性。你可以使用并发来分隔不同的功能区域，即使在这些不同功能区域的操作需要在同一时刻发生的情况下。如果不显式地使用并发，你要么被迫编写任务切换框架，要么在操作中主动地调用不相关的一段代码。
考虑一类带有用户界面的密集处理型应用程序，例如为台式计算机提供的DVD播放程序。这样一个应用程序基本上具备两套职能：它不仅要从光盘中读取数据，解码图像和声音，并把它们及时输出至视频和音频硬件，从而实现DVD的无错播放；它还要接受来自用户的输入，例如当用户单击暂停或返回菜单甚至退出按键的情况。在单个线程中，应用程序须在回放期间定期检查用户的输入，于是将DVD回放代码和用户界面代码合在一起。通过使用多线程来分隔这些关注点，用户界面代码和DVD回放代码不再需要如此紧密地交织在一起。一个线程可以处理用户界面，另一个处理DVD回放，它们之间会有交互，例如用户点击暂停，但现在这些交互直接与眼前的任务有关。
这会带来响应性的错觉，因为用户界面线程通常可以立即响应用户的请求，即使在请求被传达给工作的线程，响应为简单地显示正忙的光标或请等待的消息的情况。类似地，独立的线程常被用于运行必须在后台连续运行的任务，例如在桌面搜索程序中监视文件系统的变化。以这种方式使用线程一般会使每个线程的逻辑更加简单，因为它们之间的交互可以被限制为清晰可辨的点，而不是到处散播不同任务的逻辑。
在这种情况下，线程的数量与CPU可用内核的数量无关，因为对线程的划分是基于概念上的设计而不是试图增加吞吐量。
为了性能而使用并发
多处理器系统已经存在了几十年，但直到最近，他们几乎只能在超级计算机、大型机和大型服务器系统中才能看到。然而芯片制造商越来越倾向于多核芯片的设计，即在单个芯片上集成2、4、16或更多的处理器，从而达到比单核心更好的性能。因此，多核台式计算机，甚至多核嵌入式设备，现在越来越普遍。这些计算机的计算能力的提高不是源自使单一任务运行的更快，而是源自并行运行多个任务。在过去，程序员曾坐等他们的程序随着处理器的更新换代而变得更快，无需他们这边做出任何努力。但是现在，就像Herb Sutter所说的，“免费的午餐结束了1”。如果软件想要利用日益增长的计算能力，它必须设计为并发运行多个任务。程序员因此必须留意，而且那些迄今都忽略并发的人们必须注意它并将其加入他们的工具箱中。
有两种方式为了性能使用并发。首先，也是最明显的，是将一个单个任务分成几部分且各自并行运行，从而降低总运行时间，这就是任务并行（taskparallelism）。虽然这听起来很直观，但它可以是一个相当复杂的过程，因为在各个部分之间可能存在很多的依赖。区别可能是在过程方面——一个线程执行算法的一部分而另一个线程执行算法的另一部分——或是在数据方面——每个线程在不同的数据部分上执行相同的操作。后一种方法被称为数据并行（dataparallelism）。
容易受这种并行影响的算法常被称为易并行（embarrassinglyparallel）。抛开你可能会尴尬地面对的很容易并行化的代码这一含义，这是一件好事情。我曾遇到过的关于此算法的别的术语是自然并行（naturallyparallel）和便利并发（convenientlyconcurrent）。易并行算法具有良好的可扩展特性——随着可用硬件线程数量的提升，算法的并行性可以随之增加与之匹配。这样的一个算法是谚语“人多力量大”的完美体现。对于非易并行算法的那一部分，你可以将算法划分为一个固定（因而不可扩展）数量的并行任务。在线程之间划分任务的技巧涵盖在第8章中。
使用并发来提升性能的第二种方法是使用可用的并行方式来解决更大的问题。与其同时处理一个文件，不如酌情处理2个或10个或20个。虽然这实际上只是数据并行的一种应用，通过对多组数据同时执行相同的操作，但还是有不同的重点。处理一个数据块仍然需要同样的时间，但在相同的时间内却可以处理更多的数据。当然，这种方法也存在限制，且并非在所有情况下都是有益的，但是这种方法所带来的吞吐量提升可以让一些新玩意变得可能。例如，如果图片的各部分可以并行处理，就能提高视频处理的分辨率。
什么时候不使用并发
知道何时不使用并发与知道何时要使用它同等重要。基本上，不使用并发的唯一原因就是在收益比不上成本的时候。使用并发的代码在很多情况下难以理解，因此编写和维护的多线程代码就有直接的脑力成本，同时额外的复杂性也可能导致更多的错误。除非潜在的性能增益足够大或关注点分离得足够清晰，能抵消确保其正确所需的额外的开发时间以及与维护多线程代码相关的额外成本，否则不要使用并发。
同样地，性能增益可能不会如预期的那么大。在启动线程时存在固有的开销，因为操作系统必须分配相关的内核资源和堆栈空间，然后将新线程加入调度器中，所有这一切都要占用时间。如果在线程上运行的任务完成得很快，那么任务实际上占据的时间与启动线程的开销时间相比就显得微不足道，可能会导致应用程序的整体性能还不如通过产生线程直接执行该任务。
此外，线程是有限的资源。如果让太多的线程同时运行，则会消耗操作系统资源，并且使得操作系统整体上运行得更缓慢。不仅如此，运行太多的线程会耗尽进程的可用内存或地址空间，因为每个线程都需要一个独立的堆栈空间。对于一个可用地址空间限制为4GB的扁平架构的32位进程来说，这尤其是个问题。如果每个线程都有一个1MB的堆栈（对于很多系统来说是典型的），那么4096个线程将会用尽所有地址空间，不再为代码、静态数据或者堆数据留有空间。虽然64位（或者更大）的系统不存在这种直接的地址空间限制，它们仍然只具备有限的资源：如果你运行太多的线程，最终会导致问题。尽管线程池（参见第9章）可以用来限制线程的数量，但这并不是灵丹妙药，它们也有自己的问题。
如果客户端/服务器应用程序的服务器端为每一个链接启动一个独立的线程，对于少量的链接是可以正常工作的，但当同样的技术用于需要处理大量链接的高需求服务器时，就会因为启动太多线程而迅速耗尽系统资源。在这种场景下，谨慎地使用线程池可以提供优化的性能（参见第9章）。
最后，运行越多的线程，操作系统就需要做越多的上下文切换。每个上下文切换都需要耗费本可以花在有价值工作上的时间，所以在某些时候，增加一个额外的线程实际上会降低而不是提高应用程序的整体性能。为此，如果你试图得到系统的最佳性能，考虑可用的硬件并发（或缺乏之）并调整运行线程的数量是必需的。
为了性能优化而使用并发就像所有其他优化策略一样，它拥有极大提高应用程序性能的潜力，但它也可能使代码复杂化，使其更难理解和更容易出错。因此，只有对应用程序中的那些具有显著增益潜力的性能关键部分才值得这样做。当然，如果性能收益的潜力仅次于设计清晰或关注点分离，可能也值得使用多线程设计。
假设你已经决定确实要在应用程序中使用并发，无论是为了性能、关注点分离，或是因为“多线程星期一”，对于C++程序员来说意味着什么？
<h3>在C++中使用并发和多线程
通过多线程为并发提供标准化的支持对C++来说是新鲜事物。只有在即将到来的C++11标准中，你才能不依赖平台相关的扩展来编写多线程代码。为了理解新版本C++线程库中众多规则背后的基本原理，了解其历史是很重要的。
C++多线程历程
1998C++标准版不承认线程的存在，并且各种语言要素的操作效果都以顺序抽象机的形式编写。不仅如此，内存模型也没有被正式定义，所以对于1998 C++标准，你没办法在缺少编译器相关扩展的情况下编写多线程应用程序。
当然，编译器供应商可以自由地向语言添加扩展，并且针对多线程的C API的流行——例如在POSIX C和Microsoft Windows API中的那些——导致很多C++编译器供应商通过各种平台相关的扩展来支持多线程。这种编译器支持普遍地受限于只允许使用该平台相应的C API以及确保该C++运行时库（例如异常处理机制的代码）在多线程存在的情况下运行。尽管极少有编译器供应商提供了一个正式的多线程感知内存模型，但编译器和处理器的实际表现也已经足够好，以至于大量的多线程的C++程序已被编写出来。
由于不满足于使用平台相关的C API来处理多线程，C++程序员曾期望他们的类库提供面向对象的多线程工具。像MFC这样的应用程序框架，以及像Boost和ACE这样的C++通用类库曾积累了多套C++类，封装了下层的平台相关API并提供高级的多线程工具以简化任务。各类库的具体细节，特别是在启动新线程的方面，存在很大差异，但是这些类的总体构造存在很多共通之处。有一个为许多C++类库共有的，同时也是为程序员提供很大便利的特别重要的设计，就是带锁的资源获得即初始化（RAII, ResourceAcquisitionIsInitialization）的习惯用法，来确保当退出相关作用域的时候互斥元被解锁。
许多情况下，现有的C++编译器所提供的多线程支持，例如Boost和ACE，综合了平台相关API以及平台无关类库的可用性，为编写多线程C++代码提供一个坚实的基础，也因此大约有数百万行C++代码作为多线程应用程序的一部分而被编写出来。但缺乏标准的支持，意味着存在缺少线程感知内存模型从而导致问题的场合，特别是对于那些试图通过使用处理器硬件能力来获取更高性能，或是编写跨平台代码，但是在不同平台之间编译器的实际表现存在差异。
新标准中的并发支持
所有这些都随着新的C++11标准的发布而改变了。不仅有了一个全新的线程感知内存模型，C++标准库也被扩展了，包含了用于管理线程（参见第2章）、保护共享数据（参见第3章）、线程间同步操作（参见第4章）以及低级原子操作（参见第5章）的各个类。
新的C++线程库很大程度上基于之前通过使用上文提到的C++类库而积累的经验。特别地，Boost线程库被用作新类库所基于的主要模型，很多类与Boost中的对应者共享命名和结构。在新标准演进的过程中，这是个双向流动，Boost线程库也改变了自己，以便在多个方面匹配C++标准，因此从Boost迁移过来的用户将会发现自己非常适应。
正如本章开篇提到的那样，对并发的支持仅仅是新C++标准的变化之一，此外还存在很多对于编程语言自身的改善，可以使得程序员们的工作更便捷。这些内容虽然不在本书的论述范围之内，但是其中的一些变化对于线程库本身及其使用方式已经形成了直接的冲击。附录A对这些语言特性做了简要的介绍。
C++中对原子操作的直接支持，允许程序员编写具有确定语义的高效代码，而无需平台相关的汇编语言。这对于那些试图编写高效的、可移植代码的程序员们来说是一个真正的福利。不仅有编译器可以搞定平台的具体内容，还可以编写优化器来考虑操作的语义，从而让程序作为一个整体得到更好的优化。
C++线程库的效率
对于C++整体以及包含低级工具的C++类——特别是在新版C++线程库里的那些，参与高性能计算的开发者常常关注的一点就是效率。如果你正寻求极致的性能，那么理解与直接使用底层的低级工具相比，使用高级工具所带来的实现成本，是很重要的。这个成本就是抽象惩罚（abstractionpenalty）。
C++标准委员会在整体设计C++标准库以及专门设计标准C++线程库的时候，就已经十分注重这一点了。其设计的目标之一就是在提供相同的工具时，通过直接使用低级API就几乎或完全得不到任何好处。因此该类库被设计为在大部分平台上都能高效实现（带有非常低的抽象惩罚）。
C++标准委员会的另一个目标，是确保C++能提供足够的低级工具给那些希望与硬件工作得更紧密的程序员，以获取终极性能。为了达到这个目的，伴随着新的内存模型，出现了一个全面的原子操作库，用于直接控制单个位、字节、线程间同步以及所有变化的可见性。这些原子类型和相应的操作现在可以在很多地方加以使用，而这些地方以前通常被开发者选择下放到平台相关的汇编语言中。使用了新的标准类型和操作的代码因而具有更佳的可移植性，并且更易于维护。
C++标准库也提供了更高级别的抽象和工具，它们使得编写多线程代码更简单和不易出错。有时候运用这些工具确实会带来性能成本，因为必须执行额外的代码。但是这种性能成本并不一定意味着更高的抽象惩罚；总体来看，这种性能成本并不比通过手工编写等效的函数而招致的成本更高，同时编译器可能会很好地内联大部分额外的代码。
在某些情况下，高级工具提供超出特定使用需求的额外功能。在大部分情况下这都不是问题，你没有为你不使用的那部分买单。在罕见的情况下，这些未使用的功能会影响其他代码的性能。如果你更看重程序的性能，且代价过高，你可能最好是通过较低级别的工具来手工实现需要的功能。在绝大多数情况下，额外增加的复杂性和出错的几率远大于小小的性能提升所带来的潜在收益。即使有证据确实表明瓶颈出现在C++标准库的工具中，这也可能归咎于低劣的应用程序设计而非低劣的类库实现。例如，如果过多的线程竞争一个互斥元，这将会显著影响性能。与其试图在互斥操作上花掉一点点的时间，还不如重新构造应用程序以减少互斥元上的竞争来得划算。设计应用程序以减少竞争会在第8章中加以阐述。
在非常罕见的情况下，C++标准库不提供所需的性能或行为，这时则有必要运用特定的平台相关的工具。
平台相关的工具
虽然C++线程库为多线程和并发处理提供了颇为全面的工具，但是在所有的平台上，都会有些额外的平台相关工具。为了能方便地访问那些工具而又不用放弃使用标准C++线程库带来的好处，C++线程库中的类型可以提供一个native_handle()成员函数，允许通过使用平台相关API直接操作底层实现。就其本质而言，任何使用native_handle()执行的操作是完全依赖于平台的，这也超出了本书（同时也是标准C++库本身）的范围。
当然，在考虑使用平台相关的工具之前，明白标准库能够提供什么是很重要的，那么让我们通过一个例子来开始。
1The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software, Herb Sutter, Dr. Dobb’s Journal, 30(3), March 2005.http://www.gotw.ca/publications/concurrency-ddj.htm
本文摘自《C++并发编程实战》
《C++并发编程实战》
内容简介
《C++并发编程实战》是一本基于C++11新标准的并发和多线程编程深度指南。内容包括从std：：thread、std：：mutex、std：：future和std：：async等基础类的使用，到内存模型和原子操作、基于锁和锁数据结构的构建，再扩展到并行算法、线程管理，最后还介绍了多线程代码的测试工作。本书的附录部分还对C++11新语言特性中与多线程相关的项目进行了简要的介绍，并提供了C++11线程库的完整参考。
《C++并发编程实战》适合于需要深入了解C++多线程开发的读者，以及使用C++进行各类软件开发的开发人员、测试人员。对于使用第三方线程库的读者，也可以从本书后面的章节中了解到相关的指引和技巧。同时，本书还可以作为C++11线程库的参考工具书。
作者简介
周全，软件工程师，毕业于中国科学技术大学信息学院，现任职于中国人民银行合肥中心支行科技处。从事.NET开发多年，有较为丰富的系统集成和运维经验，对虚拟化也有较深入的研究。可以通过email: spadeq@live.com与他联系。
宋真真，网络工程师，2008年毕业于合肥工业大学计算机与信息学院，现任职于中国人民银行合肥中心支行科技处，参与软件开发、项目管理等工作，爱好数据库、编程等研究。可以通过email: hfut_szz@sina.com与她联系。
梁娟娟，2010年毕业于中国科学技术大学信息技术学院，现就职于中国人民银行合肥中心支行。
许敏，软件工程师，2005年获得软件测试工程师证书。现任职于中国人民银行合肥中心支行科技处，负责项目管理工作。可以通过Email: xu_min@sina.com与她联系。
网友评论