上篇：Real-world Concurrency（真实世界的并发）翻译&笔记

Real-world Concurrency翻译&笔记

这篇文章主要讨论了编写并发程序的主要原则，精读之后收获颇大，故作为笔记，记录于此。

I、翻译部分

Chances are you won’t actually have to write multithreaded code. But if you do, some key principles will help you master this “black art.”

Bryan Cantrill and Jeff Bonwick, Sun Microsystems(人名+公司 可以不管)

Software practitioners today could be forgiven if recent microprocessor developments have given them some trepidation about the future of software. While Moore’s law continues to hold (that is, transistor density continues to double roughly every 18 months), as a result of both intractable physical limitations and practical engineering considerations, that increasing density is no longer being spent on boosting clock rate. Instead, it is being used to put multiple CPU cores on a single CPU die. From the software perspective, this is not a revolutionary shift, but rather an evolutionary one: multicore CPUs are not the birthing of a new paradigm, but rather the progression of an old one (multiprocessing) into more widespread deployment. Judging from many recent articles and papers on the subject, however, one might think that this blossoming of concurrency is the coming of the apocalypse, that “the free lunch is over.”

有可能您不需要编写多线程代码。但是如果你这样做了，一些关键的原则将帮助你掌握这种“黑色艺术”。如果最近微处理器的发展给今天的软件从业者带来了对软件未来的恐惧，这是可以原谅的。虽然摩尔定律继续有效（即晶体管密度继续增加大约每 18 个月翻一番），这既是由于难以克服的身体限制，也是由于在治疗和康复方面的经验不足。从物理工程学的角度考虑，密度的增加已不再用于提高时钟频率。取而代之的是在单个CPU芯片上安装多个CPU内核。从从软件的角度来看，这不是一个革命性的转变，而是一个进化：多核CPU不是新模式的诞生，而是旧范式(多处理)向新模式的发展。然而，从最近许多关于这个主题的文章和论文来看，人们可能会认为这种并发性的繁荣是末日的来临，即“免费的午餐已经结束了”。

As practitioners who have long been at the coal face of concurrent systems, we hope to inject some calm reality (if not some hard-won wisdom) into a discussion that has too often descended into hysterics. Specifically, we hope to answer the essential question: what does the proliferation of concurrency mean for the software that you develop? Perhaps regrettably, the answer to that question is neither simple nor universal—your software’s relationship to concurrency depends on where it physically executes, where it is in the stack of abstraction, and the business model that surrounds it.

作为长期在并发系统领域工作的实践者，我们希望能注入一些冷静的现实观点（如果不是一些来之不易的智慧的话）的讨论。具体来说，我们希望回答一个基本问题：并发性的激增对你开发的软件意味着什么？也许令人遗憾的是，这个问题的答案既不简单也不普遍——你的软件与并发性的关系取决于它的物理执行位置、它在抽象堆栈中的位置以及围绕它的商业模式。

Given that many software projects now have components in different layers of the abstraction stack spanning different tiers of the architecture, you may well find that even for the software that you write, you do not have one answer but several: you may be able to leave some of your code forever executing in sequential bliss, and some may need to be highly parallel and explicitly multithreaded. Further complicating the answer, we will argue that much of your code will not fall neatly into either category: it will be essentially sequential in nature but will need to be aware of concurrency at some level.

鉴于现在许多软件项目的组成部分都在抽象堆栈的不同层中，跨越了体系结构的不同层，你很可能会发现，即使是你编写的软件，也不是只有一个答案，而是有几个答案：你可能可以让你的一些代码永远按顺序执行，而有些代码可能需要高度并行和明确的多线程。使答案更加复杂的是，我们认为您的大部分代码并不完全属于这两种类型：它们本质上是顺序代码，但需要在一定程度上意识到并发性。

Although we assert that less—much less—code needs to be parallel than some might fear, it is nonetheless true that writing parallel code remains something of a black art. We also therefore give specific implementation techniques for developing a highly parallel system. As such, this article is somewhat dichotomous: we try both to argue that most code can (and should) achieve concurrency without explicit parallelism, and at the same time to elucidate techniques for those who must write explicitly parallel code. This article is half stern lecture on the merits of abstinence and half Kama Sutra.

尽管我们断言，需要并行的代码比一些人担心的要少——少得多，但编写并行代码仍然是一门艺术，这是事实。因此，我们也给出了开发高度并行系统的具体实现技术。因此，这篇文章具有两面性：我们试图证明大多数代码可以(也应该)实现并行化，也试图论证并行化的必要性。这篇文章一半是关于节欲优点的严厉演讲，一半是爱经。