The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software

观看原文请移至：http://www.gotw.ca/publications/concurrency-ddj.htm

免费午餐结束：软件并发的根本转向

免费午餐已经超越了软件并发的根本转向

你的免费午餐即将结束。你能为这个做什么？关于这个你在做什么？

从Intel，AMD到Sparc和PowerPC的主要处理器制造商和架构已经没有空间，大多数传统方法都是为了提升CPU的性能。相反，驱动时钟速度和直线指令吞吐量越来越高，他们是不是把集体对超线程和多核架构。这两个功能都已经在芯片上提供; 特别是当前的PowerPC和SparcIV处理器可以提供多核，并且将在2005年由Intel和AMD推出。事实上，2004年In-Stat/ MDR秋季处理器论坛的主题是多核设备，因为许多公司展示了新的或更新的多核处理器。回顾一下，把2004年称为多核之年并不算什么。

这使我们处于软件开发的根本转折点，至少在未来几年，以及针对通用台式计算机和低端服务器的应用程序（今天这恰好占到软件售价的绝大部分）。在这篇文章中，我将描述硬件变化的面貌，为什么突然对软件有影响，并发革命对你来说具体如何，并将改变将来可能编写软件的方式。

可以说，免费的午餐已经结束了一两年了，只是我们现在才注意到。

免费午餐

有一个有趣的现象被称为“Andygiveth, and Bill taketh away.”。无论处理器有多快，软件一直在寻找新的方法来消化额外的速度。使CPU速度提高十倍，而软件通常会找到十倍的数量（或者在某些情况下，可以自由地做十倍的效率）。即使没有发布新版本或做任何特殊的事情，大多数类别的应用程序几十年来都可以获得自由和经常的​​性能提升，因为CPU制造商（主要）和内存和磁盘制造商（其次）已经可靠地实现了更新，更快的主流系统。时钟速度不是衡量性能的唯一指标，甚至是一个好的衡量指标，但这是一个有益的指标：我们习惯于看到500MHz的CPU让位给1GHz的CPU让位给2GHz的CPU等等。今天我们的主流电脑在3GHz范围内。

关键问题是什么时候结束？毕竟，摩尔定律预测指数增长，明显的指数增长不能永远持续下去，直到我们达到硬物理极限。光没有变得更快。增长最终必须放缓甚至结束。（注意：摩尔定律主要适用于晶体管密度，但在相关领域（例如时钟速度）出现了同样的指数级增长，其他空间的增长甚至更快，最明显的是数据存储爆炸，但这一重要趋势属于在另一篇文章中）。

如果你是一名软件开发人员，那么你很可能已经开始了桌面电脑性能的“免费午餐”浪潮。您的应用程序的性能是否为一些本地操作的边界？“不用担心”，传统（如果怀疑的话）“明天的处理器将有更多的吞吐量，而且无论如何，现在的应用程序越来越受到CPU吞吐量和内存速度以外因素的限制（例如，它们通常是I / O绑定，网络绑定，数据库绑定）。

Right enough, inthe past. But dead wrong for the foreseeable future.

好消息是处理器将继续变得更加强大。坏消息是，至少在短期内，增长主要来自于目前大多数情况下不适合习惯搭便车的方向。

在过去的30年中，CPU设计人员在三个主要领域取得了性能提升，其中前两个侧重于直线执行流程：

时钟速度

执行优化

高速缓存

提高时钟速度是获得更多的周期。直接更快地运行CPU意味着更快地完成相同的工作。优化执行流程是关于每个周期做更多的工作。今天的CPU具有更强大的指令，它们执行从行人到异类的优化，包括流水线，分支预测，在同一个时钟周期内执行多条指令，甚至对指令流进行重新排序，订单执行。这些技术都是为了使指令更好地执行和/或更快地执行而设计的，并且通过减少延迟并使每个时钟周期完成的工作最大化来挤压每个时钟周期中的大部分工作。

芯片设计人员面临着提供速度更快的CPU的巨大压力，他们将冒险改变程序的含义，甚至有可能破坏程序，以使其运行速度更快

除了指令重新排序和内存模型之外，请注意，我刚才称为“优化”的一些内容实际上远远超过了优化，因为它们可以改变程序的含义并导致可视化效果，从而打破合理的程序员期望。这很重要。CPU设计师通常都是理智的，调整得很好的人，他们通常不会伤害苍蝇，也不会想到会损害你的代码。但是近几年来，他们一直愿意进行积极的优化，以便在每个周期中更快地获得更多的速度，甚至完全知道这些重大的重组可能危及到代码的语义。这是Mr. Hyde的性能意愿吗？一点也不。这种意愿仅仅是芯片设计人员面临提供速度更快的CPU所面临的巨大压力的明确指标; 他们承受的压力太大，他们会冒险改变程序的含义，甚至有可能破坏程序，以使程序运行得更快。在这方面的两个值得注意的例子是写入重新排序和读取重新排序：允许处理器重新排序写入操作的后果是如此令人惊讶，并打破了很多程序员的期望，通常必须关闭该功能，因为程序员太难在存在任意写入重新排序的情况下正确地理解其程序的含义。对读取操作进行重新排序也可以产生令人惊讶的可见效果，但是更常见的是无论如何都会使其被启用，因为对于程序员来说，最后，增加片上缓存的大小就是远离RAM。主内存继续比CPU慢得多，所以把数据放在处理器上更合理 - 而且你不能靠近芯片上的距离。片上缓存大小已经飙升，而今天大多数主要的芯片供应商都会向你推销拥有2MB或更多板载L2缓存的CPU。（在提升CPU性能的三个主要历史方法中，增加缓存是唯一一个将在近期继续的缓存，稍后我会详细讨论缓存的重要性。）好的。那么这是什么意思？认识到这个列表的一个基本重要的事情是，所有这些领域都是并发不可知的。任何这些领域的加速将直接导致顺序（非并行，单线程，单进程）应用程序以及利用并发的应用程序加速。这一点很重要，因为今天的绝大多数应用程序都是单线程的，出于好的理由，我将在下面进一步讨论。

当然，编译器不得不跟上; 有时您需要重新编译应用程序，并针对特定的最低级别的CPU，以便从新的指令（如MMX，SSE）以及一些新的CPU特性和特性中受益。但是，总的来说，即使是旧的应用程序总是运行得更快，即使没有重新编译以利用最新CPU提供的所有新指令和功能。

那个世界是一个很好的地方。不幸的是，它已经消失了。

障碍，为什么你今天没有10GHz

据我们所知，CPU性能的增长在两年前就遇到了困难。大多数人最近才开始注意到。

您可以获得其他芯片的类似图表，但我要在这里使用英特尔数据。图1显示了通过时钟速度和晶体管数量推出的英特尔芯片的历史。至少现在，晶体管的数量还在不断攀升。但是，时钟速度是另外一回事。

图1：Intel CPU介绍（图表更新于2009年8月;文章原文自2004年12月起）

大约在2003年初，你会注意到以往CPU时钟速度越来越快的趋势的急剧转变。我已经添加了线条来显示最大时钟速度的极限趋势; 如细细的虚线所示，而不是继续前行的路径，这是一个明显的扁平化。由于不仅仅是一个而是几个物理问题，尤其是热（太多而且太难消散），功耗（太高）以及电流泄漏问题，因此开发更高时钟速度变得越来越困难。

快速：当前工作站中CPU的时钟速度是多少？你在10GHz运行？在Intel芯片上，我们很久以前（2001年8月）就达到了2GHz，根据2003年之前的CPU趋势，现在在2005年初，我们应该拥有第一个10GHz Pentium系列芯片。快速浏览显示，实际上，我们没有。更重要的是，这样的芯片甚至不在眼前，我们根本不知道什么时候可以看到它们的出现。

那么，那么4GHz呢？我们已经在3.4GHz了 - 当然4GHz不能太远？唉，甚至4GHz似乎确实是遥远的。在2004年中期，大概知道的是，英特尔首先推迟了到2005年推出4GHz芯片的计划，然后在2004年秋季，它完全放弃了4GHz计划。在撰写本文时，英特尔计划在2005年初进一步提高到3.73GHz（已经包括在图1中作为右上角的点），但时钟竞赛至少现在已经结束了。英特尔和大多数处理器供应商的未来在于其他芯片公司积极追求相同的新多核方向。

有一天我们可能在主流台式机上看到4GHz的CPU，但是它不会在2005年。当然，英特尔的芯片样品在实验室中运行速度更快，但只能通过英雄般的努力，不切实际的冷却设备数量。你不会在办公室有这样的冷却硬件，更不用说在飞机上计算的时候放在你的腿上。

TANSTAAFL：摩尔定律和下一代（S）

“There ain’t no such thing as a freelunch.” —R. A. Heinlein, The Moon Is a Harsh Mistress

这是否意味着摩尔定律结束了？有趣的是，一般的答案似乎是否定的。当然，就像所有的指数级进展一样，摩尔定律总有一天会结束，但是似乎还有几年的危险。尽管芯片工程师在榨取原始时钟周期方面遇到了很大的困难，但晶体管数量仍在爆炸式增长，似乎CPU在未来几年仍将继续遵循摩尔定律的吞吐量增长。

神话与现实：2 x 3GHz <6 GHz

一个结合了两个3GHz内核的双核CPU实际上提供了6GHz的处理能力。对吗？不对。即使在两个物理处理器上运行两个线程也不意味着获得两倍的性能。同样，大多数多线程应用程序在双核心机上运行速度不会快一倍。它们应该比在单核CPU上运行得更快; 性能增益不是线性的，就是这样。为什么不？

首先，核心之间存在协调开销，以确保高速缓存一致性（高速缓存和主内存的一致视图）并执行其他握手。现在，即使对于多线程应用程序，两个或四个处理器的机器实际上也不是单个CPU的两倍或四倍。即使所讨论的CPU坐在同一个芯片上，问题仍然基本相同。

其次，除非两个内核运行不同的进程，或者单个进程的不同线程独立运行，几乎从不相互等待，否则将无法得到很好的利用。（尽管如此，我还是会推测今天的单线程应用程序在实际应用中可能会看到大多数用户通过使用双核芯片而提高性能，这并不是因为额外的内核实际上在做有用的事情，而是因为它正在运行广告软件和间谍软件，这些软件侵扰了许多用户的系统，并以其他方式减慢了用户现在使用的单个CPU的速度。我决定是否增加一个CPU来运行间谍软件是解决这个问题的最佳解决方案。）

如果您运行的是单线程应用程序，那么应用程序只能使用一个内核。操作系统和应用程序可以在不同的内核上运行，但是通常操作系统并不会占用CPU空间，所以其中一个内核大部分是空闲的。（同样，间谍软件大部分时间都可以共享操作系统的内核。）

这篇文章的核心所在的关键区别在于，至少在接下来的几代处理器中，性能提升将以完全不同的方式完成。而大多数当前的应用程序将不再受益于没有重大设计的免费搭车。

对于近期的未来，意味着未来几年，新芯片的性能提升将受到三个主要途径的推动，其中只有一个与过去相同。近期未来业绩增长驱动因素是：

超线程   

多核      

高速缓存

超线程是关于在单个CPU内并行运行两个或更多的线程。超线程CPU现在已经可用，并且允许一些指令并行运行。然而，一个限制因素是，尽管一个超线程CPU有一些额外的硬件，包括额外的寄存器，但它仍然只有一个高速缓存，一个整数数学单元，一个FPU，并且通常只有一个最基本的CPU特性。超线程有时候被认为是为合理编写好的多线程应用程序提供了5％到15％的性能提升，甚至在理想的条件下为精心编写的多线程应用程序提供了多达40％的性能提升。这很好，但是它不是双倍的，并且不能帮助单线程应用程序。

多核心就是在一个芯片上运行两个或多个实际的CPU。一些芯片，包括Sparc和PowerPC，已经有了多核版本。最初的英特尔和AMD设计将于2005年到期，但它们的集成度有所不同，但在功能上是相似的。AMD似乎有一些初步的性能设计优势，比如在同一芯片上更好地集成了支持功能，而英特尔最初的入门基本上只是将两个至强芯片粘合在一个芯片上。性能增益最初应该与拥有一个真正的双CPU系统相同（只有系统会更便宜，因为主板不需要有两个插座和相关的“胶合”芯片），这意味着不到两倍即使在理想的情况下也是如此，就像今天一样，它将提升合理编写好的多线程应用程序。

最后，至少在近期内，内存缓存容量可能会持续增长。在这三个领域中，只有这个领域将广泛受益于大多数现有的应用。对于许多应用来说，片上缓存大小的持续增长对于空间的速度来说是一个非常重要和高度可用的好处。访问主内存是昂贵的，你真的不想触摸内存，如果你可以帮助它。在当今的系统中，发送到主存储器的高速缓存未命中往往花费10到50倍的时间从高速缓存中获取信息;顺便说一下，这仍然让人感到意外，因为我们都认为内存速度很快，而且与磁盘和网络相比是快速的，但是与速度更快的板上缓存相比，速度还是比较快的。如果一个应用程序的工作集适合缓存，那么我们是黄金的，如果没有，我们就不是。这就是为什么增加的缓存大小可以节省一些现有的应用程序，并为它们注入新的活力，而不需要重新设计：现有的应用程序操纵越来越多的数据，并且随着更新数据的增量更新以包含更多的新功能代码，性能敏感操作需要继续适应缓存。正如大萧条时期的老前辈们会很快提醒你的，“Cache is king.”。

（另外：这里有一个轶事来演示最近打击我的编译器团队的“space is speed”，编译器为32位和64位编译器使用相同的源代码库;代码只是编译为32位的进程或64位，64位编译器通过在64位CPU上运行获得了大量的基准性能，主要是因为64位CPU有更多的寄存器可供使用，并具有其他代码性能特点。但是数据怎么样呢？去64位并没有改变内存中大部分数据的大小，当然除了特别是指针的大小是现在的两倍之外，碰巧，我们的编译器使用指针的内部数据结构比其他类型的应用程序要重要得多，因为指针现在是8个字节，而不是4个字节，纯数据量增加了，我们看到64位编译器工作集的显着增加。更大的工作集导致了性能损失几乎完全抵消了代码执行性能的提高，我们通过更快的处理器获得了更多的寄存器。在编写本文时，64位编译器的运行速度与32位编译器相同，即使两者的源代码基本相同，而64位处理器也提供了更好的原始处理吞吐量。space is speed.）

但缓存就是关键。超线程和多核CPU对大多数当前的应用程序几乎没有影响。

那么硬件的这种变化对于我们编写软件的方式意味着什么呢？现在你可能已经注意到了基本的答案，所以让我们来考虑它的后果。

对于软件这意味着什么：下一个革命

在二十世纪九十年代，我们学会了修饰物体。从结构化编程到面向对象编程的主流软件发展的革命，是过去20年来最大的变化，可以说是过去的30年。还有其他的变化，包括最近的（也是真正有趣的）Web服务的诞生，但是我们大多数人在我们的职业生涯中没有看到什么变化，这是我们编写软件的方式的基本和深远的变化是对象改革。

到现在。

从今天开始，表演午餐不再是免费的。当然，这将继续普遍适用的性能提升，每个人都可以拿起，主要得益于缓存大小的改善。但是，如果您希望您的应用程序能够从新处理器中持续的指数吞吐量增长中受益，那么它将需要一个写得很好的并发（通常是多线程）应用程序。说起来容易做起来难，因为并不是所有的问题都是内在的并行化的，而且并发编程很难。

我可以听到抗议的吼叫：“并发？那不是新闻！人们已经在编写并发应用程序了。“的确如此。只有一小部分开发人员。

请记住，自从20世纪60年代后期以来，人们一直在做面向对象编程。但是直到20世纪90年代，OO才成为一场革命，成为主流的主流。那为什么？革命发生的原因主要在于，我们的行业受到编写规模越来越大的系统的需求的驱动，这些系统解决了越来越大的问题，并利用越来越多的CPU和存储资源。OOP在抽象和依赖管理方面的优势使其成为实现经济，可靠，可重复的大规模软件开发的必然要求。

并发性是我们编写软件的下一个主要革命

同样，我们一直在进行并发编程，因为那些黑暗的年龄，编写协程和监视器和类似爵士乐的东西。在过去的十年左右，我们目睹越来越多的程序员正在编写并发（多线程，多进程）系统。但是，一个标志着并发的重大转折点的实际革命已经很慢了。今天绝大多数的应用程序都是单线程的，出于好的理由，我将在下一节中进行总结。

顺便说一句，关于炒作的问题：人们总是很快就宣布“下一个软件开发革命”，通常是关于他们自己的全新技术。不要相信。新技术往往是真正有趣的，有时甚至是有益的，但是我们编写软件的最大的革命通常来自已经存在多年的技术，并且在向爆炸式增长转变之前已经经历了逐渐的增长。这是必要的：你只能基于一个足够成熟的技术（包括有稳定的供应商和工具支持）的软件开发革命，它通常需要任何新的软件技术至少七年，才能够广泛地没有表演悬崖和其他陷阱可用。结果是，像OO这样的真正的软件开发革命发生在几十年来一直在进行细化的技术上。即使在好莱坞，大多数真正的“一夜成名”在大休之前也确实表现了多年。

并发性是我们编写软件的下一个主要革命。不同的专家对它是否会比面向对象有所不同，但是这种对话最好留给专家看。对于技术人员来说，有趣的是，在革命的（预期的）规模以及技术的复杂性和学习曲线上，并发性与面向对象的规则是一样的。

并发的好处和代价

主流软件已经使用了并发性，特别是多线程的两个主要原因。首先是在逻辑上将自然独立的控制流分开; 例如，在我设计的数据库复制服务器中，将每个复制会话放在其自己的线程上是很自然的，因为每个会话完全独立于任何可能处于活动状态的其他会话（只要它们不在同一个数据库行上工作）。编写并发代码的第二个也是不太常见的原因是为了提高性能，要么可扩展地利用多个物理CPU，要么轻松利用应用程序其他部分的延迟; 在我的数据库复制服务器，然而，实际并发成本。一些显而易见的成本实际上并不重要。例如，是的，锁的获取成本可能会很高，但是如果明智而恰当地使用锁，那么从并发执行中获得的数据将比同步丢失的多得多，如果可以找到合理的方法来并行化操作并最小化或消除共享状态。

也许并发性的第二大成本是并不是所有的应用程序都可以并行化。稍后我会详细讲述。

并发性的最大代价可能是并发性确实很难：编程模型（这意味着程序员头脑中需要对其程序进行可靠推理的模型）比顺序控制流程难得多。

每个学习并发的人都会认为他们理解，最终发现他们认为不可能的神秘的种族，并发现他们实际上并没有真正理解它。当开发者学习并发的原因时，他们发现通常这些种族可以被合理的内部测试所捕获，并且他们达到了一个新的知识和舒适的高度。但是，除了在理解为什么以及如何进行实际压力测试的商店之外，通常不会陷入测试的是那些仅仅在真正的多处理器系统上才会出现的潜在的并发错误，在这些系统中线程不仅仅是在切换一个处理器，但他们确实同时执行，从而揭露新类错误。对于那些认为现在他们知道如何编写并发代码的人来说，这是下一个颠簸：我遇到过许多团队，即使在沉重的压力测试中，应用程序也能正常工作，并能在许多客户站点上完美运行，直到客户实际上拥有真正的多处理器机器，然后深深地感到神秘的种族和腐败开始间歇性地出现。在当今CPU环境下，重新设计应用程序以在多核机器上运行多线程，有点像学习通过跳入深处直至最容易暴露的真正平行的环境你错了。即使你有一个团队可以可靠编写安全的并发代码，还有其他的缺陷。例如，并发代码是完全安全的，但并不比单核机器上的代码快，通常是因为线程不够独立，并且对重新序列化程序执行的单个资源共享依赖。这东西变得非常微妙。

今天的绝大多数程序员并不喜欢并发性，正如15年前绝大多数程序员还没有把对象一样

就像结构化程序员学习面向对象的一个​​飞跃（什么是对象？什么是虚拟函数？我应该如何使用继承？并超出“whats”和“hows”，为什么正确的设计实践实际上是正确的？对于一个过程式程序员来说，学习并发是一个巨大的飞跃（什么是种族？什么是死锁？怎么会出现，怎样才能避免它？实际上我认为是并行的程序的序列化？消息是如何排列我的朋友的？超出了“whats”和“hows”，为什么正确的设计实践实际上是正确的？）。

今天的绝大多数程序员并不喜欢并发性，正如15年前绝大多数程序员还没有注意到对象一样。但是并发编程模型是可以学习的，特别是如果我们坚持基于消息和锁定的编程，并且一旦编程，它并不比OO更难，希望能够变得自然。只要做好准备，并允许为您和您的团队投入培训和时间。

（我故意将上面的内容限制在基于消息和锁的并发编程模型中，也有无锁编程，在Java 5和至少一个流行的C ++编译器中最直接的语言级支持，但是并发的无锁编程对于程序员来说，要比并发的基于锁的编程更难以理解和推理。大多数情况下，只有系统和库编程人员必须理解无锁编程，尽管几乎每个人都应该能够利用坦率地说，即使基于锁定的编程也是危险的）。

它对我们意味着什么呢？

1.我们已经谈到的明显的主要后果是，如果要充分利用现在已经开始可用并将在未来几年继续实现的CPU吞吐量收益，应用程序将越来越需要并发。例如，英特尔正在谈论某一天生产100核芯片; 单线程应用程序可以利用这种芯片的潜在吞吐量的至多1/100。“哦，性能没有那么重要，电脑只是越来越快”，一直是一个天真的声明，怀疑，而在不久的将来，它几乎总是是错的。

如果要充分利用持续的指数级CPU吞吐量，应用程序将越来越需要并发；效率和性能优化将会变得更重要，而不是更少。

现在，并不是所有的应用程序（或者更确切地说，应用程序的重要操作）都可以并行化。诚然，编译等一些问题几乎是可以并行的。但其他人不是; 这里通常的反例是因为一个女人生产一个婴孩需要九个月的时间，并不意味着九个女人可以在一个月内生产一个婴儿。你以前可能会遇到这种类比。但是你有没有注意到这个问题呢？下面是要问下一个使用它的人的技巧问题：你能从中得出结论：人类婴儿问题本质上不适合并行化吗？通常，把这个类比错误的人很快得出结论：它表现出一个固有的非平行问题，但实际上这不一定是正确的。如果目标是生产一个孩子，这确实是一个固有的不平行的问题。如果目标是生产很多孩子，这实际上是一个理想的可并行的问题！了解真正的目标可以使所有的差异。在考虑是否以及如何并行化软件的时候，这个基本的面向目标的原则是需要记住的。

2.也许一个不那么明显的结果是，应用程序可能越来越受到CPU限制。当然，并不是每个应用程序操作都会受到CPU的限制，即使是那些受到影响的应用程序，如果它们还不是一夜之间就不会一夜之间CPU占用，但是我们似乎已经达到了“应用程序越来越多/ O绑定或网络绑定或数据库绑定“的趋势，因为这些领域的性能仍然在迅速提高（千兆WiFi，任何人？），而传统的CPU性能增强技术已经最大化。考虑一下：我们现在停止在3GHz的范围内。因此，除了进一步缓存大小增长（这是主要的好消息），单线程程序现在可能不会再快得多了。其他的收益可能是增量的，比过去我们所看到的要小得多，例如，芯片设计人员找到了新的方法来保持管道充满并避免失速，这是已经收获了低悬的水果的地区。对新应用程序功能的需求不太可能减少，而处理大量应用程序数据的需求不可能停止加速。随着我们继续要求程序做更多的事情，他们会越来越多地发现，除非可以编写并发代码，否则它们会耗尽CPU。有两种方法可以解决这种向并发的巨变。一个是重新设计你的应用程序的并发性，如上所述。另一个是节俭，通过编写更高效，更浪费的代码。这导致了第三个有趣的结果：

3. 效率和性能优化将获得更多，而不是更少的，重要的。那些已经适应重度优化的语言将会找到新的生活; 那些不需要找到竞争的方法，变得更加高效和优化。预计对面向性能的语言和系统的长期需求将会增加。

4.最后，编程语言和系统将越来越多地被迫处理并发。Java语言从开始就包含了对并发的支持，尽管后来为了更正确和高效地进行并发编程，后来必须纠正多个版本。C ++语言长期以来一直用于编写重型多线程系统，但它并没有对并发性提供任何标准化的支持（ISOC ++标准甚至没有提到线程，故意这样做），因此通常并发性是通过使用不可移植的平台特定的并发功能和库来完成。（它通常也是不完整的;例如，静态变量只能被初始化一次，这通常要求编译器用一个锁来包装它们，但是许多C ++实现不会生成这个锁）。最后，有一些并发标准，包括pthread和OpenMP，其中一些支持隐式和显式并行。让编译器查看你的单线程程序，并自动找出隐式并行化的方法是很好的，但这些自动转换工具是有限的，并且不会产生你自己编写的显式并发控制的好处。最主流的技术围绕基于锁定的编程，这是微妙的和危险的。我们迫切需要一种更高层次的编程模型来实现并发性，而不是今天的语言。我很快就会有更多的话要说。但是这些自动转换工具是有限的，不会产生几乎你自己编码的显式并发控制的收益。最主流的技术围绕基于锁定的编程，这是微妙的和危险的。我们迫切需要一种更高层次的编程模型来实现并发性，而不是今天的语言。我很快就会有更多的话要说。但是这些自动转换工具是有限的，不会产生几乎你自己编码的显式并发控制的收益。最主流的技术围绕基于锁定的编程，这是微妙的和危险的。我们迫切需要一种更高层次的编程模型来实现并发性，而不是今天的语言。我很快就会有更多的话要说。

结论

如果您还没有这样做，现在应该仔细研究应用程序的设计，确定哪些操作现在对CPU敏感或者可能会很快出现，并确定这些位置如何从并发中受益。现在，您和您的团队也可以共同协作编程的要求，陷阱，风格和习惯用法。

一些罕见的类应用程序是自然并行的，但大多数不是。即使你确切地知道你在CPU上的位置，你也很难找出如何并行化这些操作。所有最好的理由现在就开始思考。隐含的并行化编译器可以提供一些帮助，但不要期待太多。他们不可能把你的顺序程序并行化，把它变成一个明确的并行和线程化的版本。

由于持续的缓存增长和可能的更多的增量直线控制流优化，免费的午餐会持续一段时间，但从今天开始，自助餐只能供应一个主菜和一个甜点。吞吐量增加的菲力牛排仍然在菜单上，但是现在它需要额外的开发工作，额外的代码复杂度和额外的测试工作。好消息是，对于许多类应用程序来说，额外的努力是值得的，因为并发性将使他们充分利用处理器吞吐量的持续指数增长。