Rust-并发实用指南-全-

Rust 并发实用指南（全）

原文：annas-archive.org/md5/e394776cd96e3df8f7f958aba47c8514

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

欢迎您。本书的目的是教初学者和中级 Rust 程序员如何利用 Rust 编程语言中的现代并行机器。本书将包含与 Rust 编程语言特别相关的各种信息，特别是关于其标准库的信息，但它也将包含更普遍适用的信息，但恰好是用 Rust 表达。从我个人的角度来看，Rust 本身并不是一个非常具有创造性的语言。它的主要贡献，在我看来，是将仿射类型主流化并应用于内存分配跟踪。在大多数其他方面，它是一个熟悉的系统编程语言，对于那些有 GC（垃圾收集）无编程语言背景的人来说，应该会感到熟悉——经过一些调整。这是好事，因为我们的目标是研究并发——关于这个主题的论文和书籍中有很多信息，我们理解和应用了这些概念。本书将参考许多这样的作品，其上下文是 C++、ATS、ADA 和类似的语言。

这本书面向的对象是谁

如果这是您读的第一本 Rust 编程书籍，我衷心感谢您的热情，但鼓励您寻找适合的编程语言入门介绍。这本书将直接进入正题，如果您对基础知识有疑问，可能不太合适。Rust 社区已经制作了优秀的文档，包括入门文本。《Rust 编程语言入门》（[doc.rust-lang.org/book/first-edition/](https://doc.rust-lang.org/book/first-edition/）），第一版，是许多已经在社区中的人学习这门语言的方式。这本书的第二版，在写作时仍在进行中，看起来比原始文本有所改进，也值得推荐。还有许多其他优秀的入门介绍可供购买。

要充分利用这本书

本书在相对较短的空间内涵盖了深入的主题。在整个文本中，预期读者对 Rust 编程语言感到舒适，能够访问 Rust 编译器和用于编译的计算机，并执行 Rust 程序。本书中出现的其他附加软件在第一章“预备知识 – 计算机架构和 Rust 入门”中有所介绍，并建议使用但不是强制性的。

本书的基本前提如下——并行编程很难但并非不可能。当关注计算环境并对产生的程序进行验证时，可以很好地进行并行编程。为此，每一章都是针对向读者传授章节主题的坚实基础而编写的。一旦消化了章节内容，读者将有望在该主题的现有文献中找到一条坚实的路径。在这方面，这是一本关于开始而不是结束的书。

我强烈建议读者在阅读本书时积极发挥作用，下载源代码，在阅读过程中独立调查项目，而不依赖于本书的观点，并使用您操作系统上的工具检查运行中的程序。像任何其他事情一样，并行编程能力是通过实践获得和磨练的技能。

最后一点——让学习过程按照自己的节奏进行。如果某一章节的主题没有立即在您心中扎根，那没关系。对我来说，写书的过程是灵感闪现和知识逐渐展开的过程，就像一朵花慢慢绽放。我想象阅读本书的过程也将类似。

下载示例代码文件

本书代码包托管在 GitHub 上，网址为github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。如果代码有更新，它将在现有的 GitHub 仓库中更新。

您也可以从www.packtpub.com的账户中下载本书的示例代码文件。如果您在其他地方购买了本书，您可以访问www.packtpub.com/support并注册，以便将文件直接通过电子邮件发送给您。

您可以通过以下步骤下载代码文件：

1. 在www.packtpub.com登录或注册。

2. 选择“SUPPORT”标签。

3. 点击“代码下载与勘误”。

4. 在搜索框中输入书名，并遵循屏幕上的说明。

文件下载完成后，请确保您使用最新版本的软件解压缩或提取文件夹：

• Windows 下的 WinRAR/7-Zip

• Mac 下的 Zipeg/iZip/UnRarX

• Linux 下的 7-Zip/PeaZip

我们还有来自我们丰富的图书和视频目录中的其他代码包可供选择，请访问github.com/PacktPublishing/。查看它们！

使用的约定

在本书中使用了多种文本约定。

CodeInText: 表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称。以下是一个示例：“种子是用于XorShiftRng，移动到上一行的max_in_memory_bytes和max_disk_bytes是用于 hopper。”

代码块设置如下：

fn main() {
    println!("Apollo is the name of a space program but also my dog.");
}

任何命令行输入或输出都应如下所示：

> cat hello.rs
fn main() {
 println!("Apollo is the name of a space program but also my dog.");
}
> rustc -C opt-level=2 hello.rs
> ./hello
Apollo is the name of a space program but also my dog.

粗体: 表示新术语、重要单词或屏幕上看到的单词。

警告或重要注意事项如下所示。

小贴士和技巧看起来像这样。

联系我们

欢迎提供反馈。

一般反馈: 请通过电子邮件feedback@packtpub.com发送反馈，并在邮件主题中提及书籍标题。如果您对本书的任何方面有疑问，请通过电子邮件questions@packtpub.com联系我们。

勘误表：尽管我们已经尽一切努力确保内容的准确性，但错误仍然可能发生。如果您在这本书中发现了错误，我们将不胜感激，如果您能向我们报告这一点。请访问www.packtpub.com/submit-errata，选择您的书籍，点击勘误表提交表单链接，并输入详细信息。

盗版: 如果您在互联网上发现我们作品的任何非法副本，如果您能提供位置地址或网站名称，我们将不胜感激。请通过电子邮件copyright@packtpub.com联系我们，并附上材料的链接。

如果您有兴趣成为作者：如果您在某个领域有专业知识，并且您有兴趣撰写或为书籍做出贡献，请访问authors.packtpub.com。

评论

请在您购买书籍的网站上为本书留下评论。评论帮助我们 Packt 了解您对我们的产品的看法，并且我们的作者可以看到他们对本书的反馈。谢谢！

如需了解 Packt 的更多信息，请访问 packtpub.com.

第一章：预备知识 – 机器架构和 Rust 入门

在本章中，我们将处理本书的预备知识，确保涵盖构建本书其余部分所需的基本内容。本书是关于 Rust 编程语言中的并行编程。因此，了解现代计算硬件的高级概念是至关重要的。我们需要了解现代 CPU 的工作方式，内存总线如何影响 CPU 执行工作的能力，以及对于计算机能够同时做很多事情意味着什么。此外，我们将讨论验证您的 Rust 安装，并涵盖为本书关注的两种 CPU 架构生成可执行文件。

到本章结束时，我们将：

• 讨论了 CPU 操作的概要模型

• 讨论了计算机内存的概要模型

• 对 Rust 内存模型进行了初步讨论

• 调查了为 x86 和 ARM 生成可运行的 Rust 程序

• 调查了这些程序的调试

技术要求

本章需要任何可以安装 Rust 的现代计算机。具体细节将在下面详细说明。感兴趣的读者可以选择投资 ARM 开发板。我在写作时使用了 Raspberry Pi 3 Model B。下面使用了 Valgrind 工具套件。许多操作系统捆绑了 Valgrind 包，但您可以在valgrind.org/找到您系统的进一步安装说明。使用了gdb和lldb工具，这些工具通常与 gcc 和 llvm 编译器工具链一起安装。

您可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。本章没有相关的源代码。

机器

在这本书中，无论具体是哪种 Rust 技术，我们都会尝试教授一种与现代并行计算机的机械亲和力。我们将涉及两种模型类型的并行性——并发内存操作和数据并行性。在这本书的大部分时间里，我们将专注于并发内存操作，这种并行性中，多个 CPU 争夺操作共享的、可寻址的内存。数据并行性，即 CPU 能够同时使用单一或多个指令对多个字进行操作，也会涉及到，但具体细节是 CPU 特定的，并且随着这本书的出版，必要的内建函数才刚刚在基础语言中变得可用。幸运的是，作为具有现代库管理的系统语言，Rust 将使我们能够轻松地引入适当的库并发出正确的指令，或者我们可以自己内联汇编。

关于并行机器算法的抽象构造的文献必须选择一个机器模型来操作。在文献中，并行随机访问机（PRAM）很常见。在这本书中，我们将关注两种具体的机器架构：

• x86

• ARM

这些机器被选择是因为它们很常见，并且它们各自具有在第六章，“原子——同步的基本原理”中非常重要的特定属性。实际机器在重要方面偏离了 PRAM 模型。最明显的是，实际机器具有有限的 CPU 数量和有限的 RAM 量。内存位置不是从每个 CPU 均匀可访问的；实际上，缓存层次对计算机程序的性能有重大影响。这并不是说 PRAM 是一种荒谬的简化，任何你在文献中找到的其他模型也是如此。应该理解的是，随着我们的工作，我们将需要出于必要而绘制抽象的线条，因为进一步的细节并不能提高我们解决问题的能力。我们还必须理解我们的抽象如何适合我们的工作，以及它们如何与其他人的抽象相关联，以便我们可以学习和分享。在这本书中，我们将关注理解我们机器的经验方法，包括仔细的测量、汇编代码的检查和替代实现的实验。这将被结合我们机器的抽象模型，比 PRAM 更具体，但在细节上仍然关注总缓存层、缓存大小、总线速度、微代码版本等等。鼓励读者在需要时添加更多具体性，如果他们感到有信心这么做。

CPU

CPU 是一种解释指令流并在这个过程中操作与其连接的存储和其他设备的设备。CPU 的最简单模型，也是通常在本科计算机科学中首先介绍的是，CPU 从一个模糊的地方接收一条指令，执行解释，接收下一条指令，解释它，以此类推。CPU 通过振荡电路维持内部节奏，所有指令都需要一定数量的振荡脉冲——或者称为时钟周期——来执行。在某些 CPU 模型中，每条指令将执行相同数量的时钟周期，而在其他模型中，指令的周期数将有所不同。一些 CPU 指令修改寄存器，具有非常低的延迟，并且 CPU 中内置了专门但极其有限的内存位置。其他 CPU 指令修改主存储器，RAM。其他指令在寄存器和 RAM 之间或反之移动或复制信息。RAM——其读写延迟远高于寄存器，但数量更多——以及其他存储设备，如 SSD，通过专用总线连接到 CPU。

这些总线的确切性质、它们的带宽和传输延迟，在不同机器架构之间是不同的。在一些系统中，RAM 中的每个位置都是可寻址的——这意味着它可以在恒定时间内从可用的 CPU 中读取或写入。在其他系统中，情况并非如此——一些 RAM 是 CPU 本地的，而一些是 CPU 远程的。一些指令控制特殊的硬件中断，导致内存范围被写入其他总线连接的存储设备。大多数情况下，与 RAM 相比，这些设备极其缓慢，而与寄存器相比，RAM 本身也较慢。

所有这些都是为了解释在 CPU 的最简单模型中，即指令按顺序执行的情况下，指令可能会在等待读取或写入执行的过程中停滞许多时钟周期。为此，重要的是要理解几乎所有的 CPU——特别是我们将在本书中关注的 CPU——都会执行指令的乱序执行。只要 CPU 能够证明两条指令序列对内存的访问是明显不同的——也就是说，它们不会相互干扰——那么 CPU 就是自由的，并且很可能会重新排序指令。这正是 C 语言关于未初始化内存的未定义行为如此有趣的原因之一。也许你的程序已经填充了内存，也许没有。乱序执行使得推理处理器的行为变得困难，但它的好处是 CPU 可以通过延迟在某种内存访问上停滞的指令序列来更快地执行程序。

同样地，大多数现代 CPU——特别是我们将在本书中关注的 CPU——执行分支预测。假设我们的程序中的分支在执行时倾向于以相同的方式分支——例如，假设我们有一个配置为在程序生命周期内启用的功能标志测试。执行分支预测的 CPU 将在等待其他停滞的指令流水线指令时，推测性地执行分支的一侧，该分支倾向于以某种方式分支。当分支指令序列赶上分支测试时，如果测试结果与预测一致，那么已经完成了很多工作，指令序列可以跳得很远。不幸的是，如果分支预测错误，那么所有这些先前的工作都必须被拆解并丢弃，并且必须计算正确的分支，这相当昂贵。这就是为什么你会发现，那些担心他们程序性能细节的程序员往往会担心分支，并试图移除它们。

所有这些都非常耗电，需要重新排序指令以避免停顿，或者提前执行可能会被丢弃的计算。耗电意味着发热，意味着需要冷却，这意味着更多的电力消耗。所有这些对于技术文明的可持续性来说并不一定好，这取决于所有这些电力的产生方式和废热的排放地点。为此，许多现代 CPU 集成了某种类型的电源调节功能。一些 CPU 会延长其时钟脉冲之间的时间，这意味着在一段时间内它们执行的指令比它们可能执行的要少。其他 CPU 会像平时一样快速前进，然后关闭一段时间，同时消耗最少的电力和冷却。构建和运行高效能 CPU 的确切方法远远超出了本书的范围。重要的是要理解，由于所有这些，在其他条件相同的情况下，你的程序执行速度会因运行而异，因为 CPU 会决定是否需要节省电力。我们将在下一章中看到这一点，当我们手动设置省电设置时。

内存和缓存

CPU 的内存存储，在上一个章节中提到，相当有限。它仅限于通用寄存器中的一小部分单词，以及在有限情况下的专用寄存器。寄存器由于构造和在芯片上的位置而非常快，但它们并不适合存储。现代机器通过总线或总线将 CPU 连接到主内存，这是一个非常大的随机可寻址字节的块。这种随机可寻址很重要，因为它意味着，与其他类型的存储不同，从 RAM 中检索第 0 个字节的成本与检索第 1,000,000,000 个字节的成本是相同的。我们程序员不需要做任何愚蠢的技巧来确保我们的结构出现在 RAM 的前面，以便更快地检索或修改，而物理位置在存储中对于旋转硬盘和磁带驱动器来说是一个紧迫的问题。我们的 CPU 如何与内存交互在不同的平台上有所不同，接下来的讨论在很大程度上得益于 Mark Batty 在 2014 年出版的《C11 和 C++11 并发模型》一书中对描述的借鉴。

在一个暴露顺序一致内存访问模型的机器中，每个内存加载或存储操作都必须与其他操作同步进行，包括在具有多个 CPU 或每个 CPU 有多个执行线程的系统中的情况。这限制了重要的优化——考虑在顺序一致模型中绕过内存停顿的挑战——因此，本书中考虑的处理器都不提供这种模型。它会以名称出现在文献中，因为这种模型易于推理，值得了解，尤其是在研究原子文献时。

x86 平台表现得像顺序一致，除了每个执行线程在写入被刷新到主内存之前都维护一个 FIFO 缓冲区。此外，还有一个全局锁用于协调执行线程之间的原子读和写操作。这里有很多东西需要解释。首先，我使用load和store与read和write互换使用，正如大多数文献所做的那样。还有平载荷/存储和原子载荷/存储之间的变体区别。原子载荷/存储是特殊的，因为它们的效果可以在执行线程之间进行协调，从而允许以不同级别的保证进行协调。x86 处理器平台提供了强制刷新写入缓冲区的栅栏指令，这会阻止其他尝试访问已写入主内存范围的线程执行，直到刷新完成。这就是全局锁的作用。如果没有原子性，写入将会随意刷新。在 x86 平台上，对内存中可寻址位置的写入是一致的，这意味着它们是全局有序的，并且读取将按照写入的顺序看到该位置上的值。与 ARM 相比，x86 上实现这一功能的方式非常简单——写入直接写入主内存。

让我们来看一个例子。从 Batty 的优秀论文中汲取灵感，考虑一个场景，其中父线程将两个变量x和y设置为 0，然后创建了两个线程，比如叫做A和*B*。线程A负责将x设置为，然后y设置为 1，而线程B负责将*x*的值加载到一个名为thr_x的线程局部变量中，将*y*的值加载到一个名为thr_y的线程局部变量中。这看起来可能如下所示：

WRITE x := 0
WRITE y := 0
[A] WRITE x := 1
[A] WRITE y := 1
FLUSH A
[B] READ x
[B] WRITE thr_x := x
[B] READ y
[B] WRITE thr_y := y

在这个特定的例子中，thr_x == 1 和 thr_y == 1。如果 CPU 按照不同的顺序执行刷新操作，这个结果就会不同。例如，看看以下内容：

WRITE x := 0
WRITE y := 0
[A] WRITE x := 1
[A] WRITE y := 1
[B] READ x
[B] WRITE thr_x := x
FLUSH A
[B] READ y
[B] WRITE thr_y := y

这种情况的结果是thr_x == 0和thr_y == 1。在没有其他协调的情况下，唯一的其他有效交错是thr_x == 0和thr_y == 0。也就是说，由于 x86 上的写缓冲区，线程 A 中*x*的写入永远不会重新排序到在y: thr_x == 1和thr_y == 0的写入之后发生。除非你喜欢将这个小程序作为客厅魔术，否则这真的很糟糕。我们希望程序具有确定性。为此，x86 提供了不同的栅栏和锁指令，这些指令控制线程何时以及如何刷新它们的本地写缓冲区，以及何时以及如何从主内存中读取字节数据。这里的精确交互是复杂的。我们将在第三章《Rust 内存模型——所有权、引用和操作》和第六章《原子操作——同步的原始操作》中详细讨论这个问题。简单来说，现在有一个SFENCE指令可用，它可以强制实现顺序一致性。我们可以如下使用这个指令：

WRITE x := 0
WRITE y := 0
[A] WRITE x := 1
[A] WRITE y := 1
[A] SFENCE        [B] SFENCE
                  [B] READ x
                  [B] WRITE thr_x := x
                  [B] READ y
                  [B] WRITE thr_y := y

由此，我们得到thr_x == 1和thr_y == 1。ARM 处理器略有不同——1/0 是一个有效的交错。ARM 没有全局锁，没有栅栏，也没有写缓冲区。在 ARM 中，一系列指令——称为传播列表，原因将在后面阐明——处于未提交状态，这意味着发起指令的线程会将其视为正在执行，但它们尚未传播到其他线程。这些未提交的指令可能已经执行——导致内存中的副作用，或者没有执行，允许进行推测执行和在前一节中讨论的其他性能技巧。具体来说，读取可能从线程的本地传播列表中满足，但写入则不行。分支指令会导致导致分支指令的传播列表被提交，可能不是程序员指定的顺序。内存子系统会跟踪哪些传播列表被发送到哪些线程，这意味着线程的私有加载和存储可能是不按顺序的，而提交的加载和存储在线程之间可能看起来是不按顺序的。在 ARM 上，通过内存子系统的更积极参与来维护一致性。

在 x86 架构中，主内存是执行操作的对象，而在 ARM 架构中，内存子系统会对请求做出响应，并且可能会使之前的未提交请求失效。写请求涉及一个读响应事件，通过这个事件可以唯一识别，而读请求必须引用一个写操作。

这设置了一个数据依赖链。读响应可能在稍后失效，但写操作则不行。每个位置都会收到一个一致性提交排序，它记录了全局的写操作顺序，这个顺序是按照线程将传播列表传播到线程时构建的。

这非常复杂。最终结果是，对线程视图中的内存的写入可能不是按照程序员顺序进行的，提交到主内存的写入也可能不是按顺序进行的，并且读取请求也可能不是按程序员顺序进行的。因此，以下代码是完美的，因为我们示例中没有分支：

WRITE x := 0
WRITE y := 0
[A] WRITE x := 1
[B] READ x
[A] WRITE y := 1
[B] WRITE thr_y := y
[B] WRITE thr_x := x
[B] READ y

ARM 提供了控制依赖关系的指令，称为屏障。ARM 中有三种依赖类型。地址依赖意味着使用加载操作来计算访问内存的地址。控制依赖意味着导致内存访问的程序流程依赖于一个加载操作。我们已经熟悉数据依赖。

虽然有大量的主内存可用，但它并不特别快。好吧，让我们澄清一下。这里的“快”是一个相对术语。在真空中，光子每 1 纳秒大约可以传播 30.5 厘米，这意味着在理想情况下，我位于美国西海岸，应该能够向美国东海岸发送一条消息，并在大约 80 毫秒内收到回复。当然，我在忽略请求处理时间、互联网的现实以及其他因素；我们只是在处理大致的数字。考虑到 80 毫秒是 8,000,000 纳秒。从 CPU 到主内存的读取操作大约需要 100 纳秒，具体取决于你的特定计算机架构、芯片的细节以及其他因素。所有这些都是为了澄清，当我们说“并不特别快”时，我们是在正常人类时间尺度之外工作的。

有时很难避免误判事物是否足够快。比如说，我们有一个 4 GHz 的处理器。每纳秒我们有多少个时钟周期？结果是 4 个。比如说，我们有一个需要访问主内存的指令——记住，这需要 100 纳秒——并且恰好能在 4 个周期内，或者 1 纳秒内完成其工作。那么这条指令将在等待时停滞 99 纳秒，这意味着我们可能失去了 99 条本可以由 CPU 执行的指令。CPU 将通过其优化技巧弥补一些损失。这些技巧只能走这么远，除非我们的计算非常、非常幸运。

为了避免主内存对计算性能的影响，处理器制造商在处理器和主内存之间引入了缓存。如今，许多机器都有三层数据缓存，以及一个指令缓存，称为 dCACHE 和 iCACHE，这些工具我们将在后面使用。您会发现 dCACHE 现在通常由三层组成，每一层都比上一层大，但出于成本或功耗的考虑也较慢。最低、最小的层被称为 L1，接下来是 L2，以此类推。CPU 从主内存中以工作块——或者简单地说是块——的形式读取到缓存中，这些块的大小与被读取的缓存大小相同。内存访问将优先在 L1 缓存上进行，然后是 L2，然后是 L3，以此类推，每个级别的缺失和块读取都会带来时间上的惩罚。然而，缓存命中却比直接访问主内存快得多。L1 dCACHE 引用为 0.5 纳秒，足够快，以至于我们假设的 4 周期指令比所需的内存访问慢 8 倍。L2 dCACHE 引用为 7 纳秒，仍然比主内存好得多。当然，具体的数字会因系统而异，我们将在下一章中做很多工作来直接测量它们。缓存一致性——保持高命中率与缺失率的比例——是构建现代机器上快速软件的一个重要组成部分。在这本书中，我们永远无法摆脱 CPU 缓存。

内存模型

处理器处理内存的细节既复杂又非常特定于该处理器。编程语言——在这里 Rust 也不例外——发明了一种内存模型来掩盖所有支持的处理器的细节，同时，理想情况下，给程序员足够的自由来利用每个处理器的特定功能。系统语言也倾向于以绝对自由的形式允许从语言内存模型中逃脱，这正是 Rust 在不安全方面的特点。

在其内存模型方面，Rust 深受 C++的启发。Rust 中暴露的原子排序是 LLVM 的，也就是 C++11 的。这是一件好事——任何与 C++或 LLVM 相关的文献都将立即适用于 Rust。内存顺序是一个复杂的话题，当学习时，依赖为 C++编写的材料通常非常有帮助。这在研究无锁/等待自由结构——我们将在本书后面看到——时尤为重要，因为关于这些主题的文献通常用 C++来讨论。考虑到 C11 编写的文献也适用，尽管可能不太直接。

现在并不是说 C++程序员会立即在并发 Rust 中感到舒适。这些概念会熟悉，但并不完全正确。这是因为 Rust 的内存模型还包括一个关于引用消耗的概念。在 Rust 中，内存中的某个对象必须使用零次或一次，但不能更多。顺便提一下，这是线性类型理论中一种称为仿射类型的版本的应用，如果您想了解更多关于这个主题的内容。现在，以这种方式限制内存访问的后果是，Rust 能够在编译时保证安全的内存访问——线程不能在不协调的情况下同时引用内存中的同一位置；同一线程中的无序访问是不允许的，等等。Rust 代码内存安全，无需依赖垃圾回收器。根据本书的评估，内存安全是一个很好的胜利，尽管引入的限制确实使得某些在 C++或类似语言中更易于构建的结构实现变得更加复杂。

这是一个我们将在第三章中更详细讨论的主题，Rust 内存模型——所有权、引用和操作。

准备工作

现在我们已经掌握了机器，这本书将处理我们需要在 Rust 编译器上同步的内容。Rust 有三种频道可供选择——稳定版、测试版和夜间版。Rust 遵循六周发布周期。每天夜间频道都会更新，包含自前一天以来 master 分支上所有新提交的补丁。与测试版和稳定版相比，夜间频道是特殊的，因为它是唯一一个能够编译夜间功能的编译器版本。Rust 对向后兼容性非常认真。语言变更建议在夜间版本中实施，由社区讨论，并在一段时间内使用后，才会从夜间版本状态提升到语言本身。测试版每六周从当前夜间版滚动更新。稳定版也同时从测试版滚动更新，每六周一次。

这意味着编译器的新稳定版本最多只有六周的历史。您选择哪个频道来工作取决于您和组织。我所了解的大多数团队都使用 nightly 版本并发布稳定版本，因为生态系统中的许多重要工具——如 clippy 和 rustfmt——仅通过 nightly 功能可用，但稳定频道提供了稳定的开发目标。您会发现，出于这个原因，许多库在 crate 生态系统中都努力保持稳定。

除非另有说明，否则本书将专注于稳定渠道。我们需要安装两个目标——一个用于我们的 x86 机器，另一个用于我们的 ARMv7。您的操作系统可能已经为您打包了 Rust——恭喜！——但社区倾向于推荐使用rustup，尤其是在管理多个、版本固定的目标时。如果您不熟悉rustup，可以在rustup.rs找到对其使用和说明的令人信服的解释。如果您正在为在运行rustup的机器上使用的 Rust 目标进行安装，它将执行必要的三元组检测。假设您的机器中有一个 x86 芯片并且正在运行 Linux，那么以下两个命令将产生相同的结果：

> rustup install stable

> rustup target add x86_64-unknown-linux-gnu

这两个命令都将指示rustup跟踪目标x86_64-unknown-linux-gnu并安装 Rust 的稳定渠道版本。如果您正在运行 OS X 或 Windows，第一个变体将安装一个稍微不同的三元组，但芯片才是真正重要的。第二个目标，我们需要更精确一些：

> rustup target add stable-armv7-unknown-linux-gnueabihf

现在您可以为您的开发机器、x86（这可能是同一件事）以及运行 Linux 的 ARMv7（如现成的 RaspberryPi 3）生成 x86 二进制文件。如果您打算为 ARMv7 生成可执行文件——如果您有或可以获取芯片，则建议这样做——那么您还需要安装适当的交叉编译器来链接。在基于 Debian 的开发系统上，您可以运行以下命令：

> apt-get install gcc-arm-linux-gnueabihf

指令将因操作系统而异，老实说，这可能是设置交叉编译项目最棘手的部分。不要绝望。如果迫不得已，您总是可以在主机上编译。编译将会很慢。在我们进入有趣的部分之前的最后一步设置是告诉 cargo 如何链接我们的 ARMv7 目标。现在，请注意，在本书写作时，交叉编译是 Rust 社区的一个活跃的研究领域。以下配置文件的调整可能在这本书出版和您阅读它之间有所变化。抱歉。Rust 社区文档肯定会帮助弥补一些差异。无论如何，根据您的操作系统，将以下内容——或类似内容——添加到~/.cargo/config：

[target.armv7-unknown-linux-gnueabihf]
linker = "arm-linux-gnueabihf-gcc"

如果不存在~/.cargo/config，请使用前面的内容创建它。

有趣的部分

让我们创建一个默认的 cargo 项目，并确认我们能否为我们的机器生成适当的汇编代码。这样做将是本书的一个重要支柱。现在，选择磁盘上的一个目录来放置默认项目，并导航到那里。这个例子将使用~/projects，但确切路径无关紧要。然后，生成默认项目：

~projects > cargo new --bin hello_world
     Created binary (application) `hello_world` project

好吧，用一些 x86 汇编代码来奖励自己吧：

hello_world > RUSTFLAGS="--emit asm" cargo build --target=x86_64-unknown-linux-gnu
   Compiling hello_world v0.1.0 (file:///home/blt/projects/hello_world)
       Finished dev [unoptimized + debuginfo] target(s) in 0.33 secs
hello_world > file target/x86_64-unknown-linux-gnu/debug/deps/hello_world-6000abe15b385411.s
target/x86_64-unknown-linux-gnu/debug/deps/hello_world-6000abe15b385411.s: assembler source, ASCII text

请注意，如果您在 OS X x86 上编译 Rust 二进制文件，则它可能无法在 Linux x86 上运行，反之亦然。这是由于操作系统自身接口的差异造成的。您最好在 x86 Linux 机器或 x86 OS X 机器上编译，并在那里运行二进制文件。这正是本书中展示的材料所采取的方法。

话虽如此，用一些 ARMv7 汇编代码奖励一下自己吧：

hello_world > RUSTFLAGS="--emit asm" cargo build --target=armv7-unknown-linux-gnueabihf
   Compiling hello_world v0.1.0 (file:///home/blt/projects/hello_world)
       Finished dev [unoptimized + debuginfo] target(s) in 0.45 secs
hello_world > file target/armv7-unknown-linux-gnueabihf/debug/deps/hello_world-6000abe15b385411.s
target/armv7-unknown-linux-gnueabihf/debug/deps/hello_world-6000abe15b385411.s: assembler source, ASCII text

当然，如果您想构建发布版本，只需给 cargo 传递 --release 标志即可：

hello_world > RUSTFLAGS="--emit asm" cargo build --target=armv7-unknown-linux-gnueabihf --release
Compiling hello_world v0.1.0 (file:///home/blt/projects/hello_world)
Finished release [optimized] target(s) in 0.45 secs
hello_world > wc -l target/armv7-unknown-linux-gnueabihf/
debug/   release/
hello_world > wc -l target/armv7-unknown-linux-gnueabihf/*/deps/hello_world*.s
 1448 target/armv7-unknown-linux-gnueabihf/debug/deps/hello_world-6000abe15b385411.s
  101 target/armv7-unknown-linux-gnueabihf/release/deps/hello_world-dd65a12bd347f015.s
 1549 total

比较生成的代码差异很有趣——并且富有教育意义！值得注意的是，发布编译将完全删除调试信息。说到调试器，让我们来谈谈调试器。

调试 Rust 程序

根据您的语言背景，Rust 中的调试情况可能会非常熟悉和舒适，或者可能会让您觉得有点简陋。Rust 依赖于其他编程语言常用的调试工具——gdb 或 lldb。两者都可以工作，尽管从历史上看，lldb 一直存在一些问题，并且直到大约 2016 年中旬，这两个工具才支持未混淆的 Rust。让我们尝试在上一节中的 hello_world 上使用 gdb：

hello_world > gdb target/x86_64-unknown-linux-gnu/debug/hello_world
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from target/x86_64-unknown-linux-gnu/debug/hello_world...done.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/blt/projects/hello_world/target/x86_64-unknown-linux-gnu/debug/hello_world.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) run
Starting program: /home/blt/projects/hello_world/target/x86_64-unknown-linux-gnu/debug/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Hello, world!
[Inferior 1 (process 15973) exited normally]

让我们也尝试一下 lldb:

hello_world > lldb --version
lldb version 3.9.1 ( revision )
hello_world > lldb target/x86_64-unknown-linux-gnu/debug/hello_world
(lldb) target create "target/x86_64-unknown-linux-gnu/debug/hello_world"
Current executable set to 'target/x86_64-unknown-linux-gnu/debug/hello_world' (x86_64).
(lldb) process launch
Process 16000 launched: '/home/blt/projects/hello_world/target/x86_64-unknown-linux-gnu/debug/hello_world' (x86_64)
Hello, world!
Process 16000 exited with status = 0 (0x00000000)

任何一个调试器都是可行的，并且强烈建议您选择适合您调试风格的那个。这本书将倾向于使用 lldb，因为作者有模糊的个人偏好。

在 Rust 开发（以及本书的其他部分）中，您通常会看到的另一个工具集是 valgrind。由于 Rust 是内存安全的，您可能会想知道 valgrind 何时会被使用。好吧，每当您使用 unsafe 时。Rust 中的 unsafe 关键字在日常代码中并不常见，但有时会出现在从热点代码路径中挤出额外百分点的场景中。请注意，unsafe 块将绝对会出现在这本书中。如果我们对 hello_world 运行 valgrind，我们会得到预期的无泄漏结果：

hello_world > valgrind --tool=memcheck target/x86_64-unknown-linux-gnu/debug/hello_world
==16462== Memcheck, a memory error detector
==16462== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==16462== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==16462== Command: target/x86_64-unknown-linux-gnu/debug/hello_world
==16462==
Hello, world!
==16462==
==16462== HEAP SUMMARY:
==16462==     in use at exit: 0 bytes in 0 blocks
==16462==   total heap usage: 7 allocs, 7 frees, 2,032 bytes allocated
==16462==
==16462== All heap blocks were freed -- no leaks are possible
==16462==
==16462== For counts of detected and suppressed errors, rerun with: -v
==16462== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

在 Rust 程序中分析内存使用是编写性能关键型项目时的一项重要日常任务。为此，我们使用 Massif，堆分析器：

hello_world > valgrind --tool=massif target/x86_64-unknown-linux-gnu/debug/hello_world
==16471== Massif, a heap profiler
==16471== Copyright (C) 2003-2015, and GNU GPL'd, by Nicholas Nethercote
==16471== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==16471== Command: target/x86_64-unknown-linux-gnu/debug/hello_world
==16471==
Hello, world!
==16471==

分析缓存也是一个重要的常规任务。为此，我们使用 cachegrind，缓存和分支预测分析器：

hello_world > valgrind --tool=cachegrind target/x86_64-unknown-linux-gnu/debug/hello_world
==16495== Cachegrind, a cache and branch-prediction profiler
==16495== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al.
==16495== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==16495== Command: target/x86_64-unknown-linux-gnu/debug/hello_world
==16495==
--16495-- warning: L3 cache found, using its data for the LL simulation.
Hello, world!
==16495==
==16495== I   refs:      533,954
==16495== I1  misses:      2,064
==16495== LLi misses:      1,907
==16495== I1  miss rate:    0.39%
==16495== LLi miss rate:    0.36%
==16495==
==16495== D   refs:      190,313  (131,906 rd   + 58,407 wr)
==16495== D1  misses:      4,665  (  3,209 rd   +  1,456 wr)
==16495== LLd misses:      3,480  (  2,104 rd   +  1,376 wr)
==16495== D1  miss rate:     2.5% (    2.4%     +    2.5%  )
==16495== LLd miss rate:     1.8% (    1.6%     +    2.4%  )
==16495==
==16495== LL refs:         6,729  (  5,273 rd   +  1,456 wr)
==16495== LL misses:       5,387  (  4,011 rd   +  1,376 wr)
==16495== LL miss rate:      0.7% (    0.6%     +    2.4%  )

这些工具将在整本书中以及许多比 hello_world 更有趣的项目中使用。但 hello_world 是在这篇文章中实现的第一个交叉编译，这可不是一件小事。

摘要

在本章中，我们讨论了本书的预备知识、现代 CPU 的机器架构以及内存的加载和存储可能如何交织出令人惊讶的结果，说明了我们需要某种同步来处理计算的需求。这种同步的需求将推动本书的大部分讨论。我们还讨论了安装 Rust、编译器的通道以及我们专注于稳定通道的意图。我们还为 x86 和 ARM 系统编译了一个简单的程序。我们还讨论了我们简单程序的调试和性能分析，这主要是作为工具的证明概念。下一章，第二章，顺序 Rust 性能和测试，将更深入地探讨这个领域。

进一步阅读

在每一章的结尾，我们将包括一个参考文献列表，这些参考文献强烈推荐给希望进一步深入研究章节中讨论的主题的读者，相关 Rust 社区讨论的链接，或重要工具的文档链接。参考文献可能出现在多个章节中，因为如果某件事很重要，它值得重复。

• 并行算法导论，1992 年，约瑟夫·贾贾。这是一本优秀的教科书，介绍了重要的抽象模型。这本书显著关注算法的抽象实现，那时缓存一致性和指令流水线不太重要，所以如果你要找一本，请注意这一点。

• 程序员应了解的内存知识，2006 年，乌尔里希·德雷珀。这是一本经典书籍，详细描述了现代计算机中内存的工作原理，尽管这本书是在写作本书时十二年前的作品。

• 计算机架构：定量方法，2011 年，约翰·亨尼西和戴维·帕特森。这是一本经典书籍，更多地面向计算机架构师而不是软件工程师。尽管如此，即使你跳过其中的电路图，深入研究这本书也是值得的。

• C11 和 C++11 并发模型，2014 年，马克·巴蒂。巴蒂形式化了 C++11/C11 内存模型，如果你能掌握他的逻辑语言，这是一种学习内存模型及其后果的极好方式。

• LLVM 原子指令和并发指南，可在llvm.org/docs/Atomics.html找到。 Rust 特别记录了其并发内存模型为 LLVM 模型。本指南及其链接的文档将是阅读本书的任何 Rust 程序员的熟悉领域。

• 缓存推测侧信道，2018 年，ARM。分支推测执行导致令人惊讶的信息泄露。ARM 的这篇论文对 ARM 上的推测执行进行了非常清晰的讨论，以及整洁的示例。

• std::memory_order 可在 en.cppreference.com/w/cpp/atomic/memory_order 查找。虽然这份文档涵盖了 C++ 中定义的内存顺序，但其关于 C++ 内存顺序保证后果的示例既直接又具有说明性。

• Valgrind 用户手册 可在 valgrind.org/docs/manual/manual.html 查找。我们将广泛使用 Valgrind，对于任何系统程序员来说，熟悉这些工具都是非常值得的。文档不可避免地触及了与本书相同的一些材料，并可能有助于从不同的角度阐明问题。

• 编译器探索器 可在 rust.godbolt.org/ 查找。编译器探索器 更多的是一个设计精良的在线工具，而不是一份论文。它允许轻松进行交叉编译，并提供指令的简化解释。

第二章：顺序 Rust 性能和测试

"先让它工作，然后让它美观，然后如果你真的、真的需要，再让它快速。"

• 乔·阿姆斯特朗

在上一章中，我们讨论了现代计算机架构的基础——CPU 及其功能、内存层次结构及其相互作用。我们简要介绍了 Rust 程序的调试和性能分析。在本章中，我们将继续这一讨论，深入探讨顺序 Rust 程序的性能特性，暂时推迟对并发性能的考虑。我们还将讨论用于展示 Rust 程序适用性的测试技术。为什么在一本关于并行编程的书中，我们会专门用一整章来讨论顺序程序？我们在这种顺序环境中所讨论的技术适用于并行环境，并且至关重要。在这里我们所获得的是关注的重点——快速且正确——尽管如此，我们将在适当的时候讨论并行编程。同样重要的是要理解，快速并行代码的生产与快速顺序代码的生产是密不可分的。这是因为我们将在整本书中处理的一个冷酷、严峻的数学现实。

到本章结束时，我们将：

• 已经了解了 Amdahl 定律和 Gustafson 定律

• 已经调查了 Rust 标准库HashMap的内部结构

• 能够使用 QuickCheck 对替代 HashMap 实现进行随机验证

• 能够使用 American Fuzzy Lop 来演示同一

• 已使用 Valgrind 和 Linux Perf 来检查 Rust 软件的性能

技术要求

本章需要安装一个可工作的 Rust 环境。验证安装的详细步骤在第一章，预备知识——机器架构和 Rust 入门中有所介绍。这里将使用 Valgrind 工具集。许多操作系统捆绑了 valgrind 包，但您可以在valgrind.org/找到您系统的进一步安装说明。Linux Perf 也被许多 Linux 发行版捆绑。本章所需的其他任何软件都将作为文本的一部分安装。

您可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。本章的源代码位于Chapter02目录下。

递减回报

严峻的事实是，当将越来越多的并发计算资源应用于问题时，回报是递减的。执行并行计算意味着一些协调开销——在存在屏障或围栏的情况下，创建新线程、分块数据和内存总线问题。并行计算不是免费的。考虑这个Hello, world!程序：

fn main() {
    println!("GREETINGS, HUMANS");
}

很简单，对吧？编译并运行它 100 次：

hello_worlds > rustc -C opt-level=3 sequential_hello_world.rs
hello_worlds > time for i in {1..100}; do ./sequential_hello_world > /dev/null; done

real    0m0.091s
user    0m0.004s
sys     0m0.012s

现在，考虑基本上相同的程序，但涉及到创建线程的开销：

use std::thread;

fn main() {
    thread::spawn(|| println!("GREETINGS, HUMANS"))
        .join()
        .unwrap();
}

编译并运行它 100 次：

hello_worlds > rustc -C opt-level=3 parallel_hello_world.rs
hello_worlds > time for i in {1..100}; do ./parallel_hello_world > /dev/null; done

real    0m0.115s
user    0m0.004s
sys     0m0.012s

这意味着在我的测试系统中线程创建的时间为 0.24 毫秒。当然，这是在没有任何同步的情况下。关键是，这并不是免费的。它也不是魔法。假设你有一个程序在一个处理器上运行需要 24 小时，并且程序中有一部分必须顺序执行，总共消耗了总运行时间的 1 小时。剩下的 23 小时代表可以并行运行的计算。如果这个计算很重要并且需要尽快完成，那么可能会倾向于投入尽可能多的硬件。你应该期望有多大的改进？

对于这个问题的一个众所周知的答案是阿姆达尔定律。它表明计算的加速与顺序部分所占时间的倒数加上并行时间所占百分比除以总新计算单元数成比例，即1/(s + p / N)。当N趋向于无穷大时，1/s == 1/(1-p)，在我们的例子中，1/(1 - (23/24)) = 24。也就是说，你所能期望的最大加速因子是 24 倍，具有无限额外的容量。哎呀。

阿姆达尔定律有点悲观，正如 John Gustafson 在 1988 年重新评估阿姆达尔定律时所指出的：

“在桑迪亚国家实验室，我们目前正在研究涉及大规模并行处理的项目。对于大规模并行化的可行性存在相当多的怀疑；这种怀疑主要集中在阿姆达尔定律上，这是 Gene Amdahl 在 1967 年提出的一个论点，即即使在一个给定问题中串行工作的比例很小，比如说 s，那么从无限数量的并行处理器中获得的最大加速比也只有 1/s。我们现在有一个 1024 处理器系统的计时结果，证明了阿姆达尔 1967 年论点背后的假设对于当前的大规模并行方法是不适当的。”

古斯塔夫森认为，实际的工作负载会将计算的时间因素视为固定，并相应地调整输入工作量。在一些假设的、非常重要的计算中，我们会认为 24 小时是可以接受的，并且随着可用的处理器总数增加，我们会急忙找出如何增加更多的计算，以便将时间恢复到一天。随着总工作量的增加，计算的串行部分趋向于零。这本身可能有些乐观，并且显然不适用于没有更多数据集可用的问题。通信开销没有包含在这两种分析中。

最终，必须内化的东西是——并行计算会带来递减的回报。具体如何形成取决于你的问题、机器等等，但这是事实。程序员必须做的是弯曲这条曲线，即减少串行计算所占的时间百分比，要么通过增加每个古斯塔夫森的并行计算相对部分，使用更大的数据集，要么通过优化串行计算的运行时间。本章的剩余部分将专注于后者——提高串行计算的运行时间。

性能

在本节中，我们将关注一个常见数据结构的串行性能——关联数组。我们将应用上一章中学习的工具来探测不同的实现。我们将关注关联数组，因为它是一个相当熟悉的领域，在计算机科学入门课程中研究过，并且在大多数高级语言中默认可用，Rust 也不例外，除了高级位之外。我们将首先查看 Rust 的关联数组，它被称为std::collections::HashMap。

标准库 HashMap

让我们探索一下HashMap的内部结构。我发现，检查不熟悉的数据结构的一个好起点是直接跳到源代码中的结构定义本身。特别是在 Rust 代码库中，会有公共的rustdoc注释和私有的注释来解释实现目标。鼓励读者亲自检查HashMap的注释。在这本书中，我们检查的是 Rust 的 SHA da569fa9ddf8369a9809184d43c600dc06bd4b4d。src/libstd/collections/hash/map.rs中的注释解释说，HashMap是用线性探测罗宾汉桶窃取实现的。线性探测意味着我们将发现HashMap是用单元格存储实现的——可能是因为我们将讨论的原因，它可能是一个连续的内存结构，并且应该能够直接理解实现，线性探测是实现关联数组的常用方法。罗宾汉桶窃取可能不太常见，但私有的注释将其描述为“这个哈希表中的主要性能技巧”，然后引用了 Pedro Celis 1986 年的罗宾汉哈希法：

"如果一个插入操作与现有元素冲突，并且该元素的“探测距离”（元素与其理想位置的距离）高于我们已探测的距离，则交换这两个元素。"

如果你亲自提取论文，你还会进一步发现：

"(罗宾汉哈希)导致了一种新的搜索算法，该算法在表几乎满的情况下平均只需要 2.6 次探测即可成功搜索。不成功的搜索只需要 O(ln n)次探测。"

还不错。这里是HashMap：

pub struct HashMap<K, V, S = RandomState> {
    // All hashes are keyed on these values, to prevent 
    // hash collision attacks.
    hash_builder: S,

    table: RawTable<K, V>,

    resize_policy: DefaultResizePolicy,
}

好吧，所以，它与RawTable<K, V>交互，我们可以跳转到那个定义：

pub struct RawTable<K, V> {
    capacity_mask: usize,
    size: usize,
    hashes: TaggedHashUintPtr,

    // Because K/V do not appear directly in any of the
    // types in the struct, inform rustc that in fact 
    // instances of K and V are reachable from here.
    marker: marker::PhantomData<(K, V)>,
}

但也许这不是最具有启发性的结构定义。集合上的常见操作通常是深入挖掘的好地方，所以让我们看看HashMap::insert：

    pub fn insert(&mut self, k: K, v: V) -> Option<V> {
        let hash = self.make_hash(&k);
        self.reserve(1);
        self.insert_hashed_nocheck(hash, k, v)
    }

然后进入HashMap::reserve：

    pub fn reserve(&mut self, additional: usize) {
        let remaining = self.capacity() - self.len(); // this can't 
        overflow
        if remaining < additional {
            let min_cap = 
            self.len().checked_add(additional)
                      .expect("reserve overflow");
            let raw_cap = self.resize_policy.raw_capacity(min_cap);
            self.resize(raw_cap);
        } else if self.table.tag() && remaining <= self.len() {
            // Probe sequence is too long and table is half full,
            // resize early to reduce probing length.
            let new_capacity = self.table.capacity() * 2;
            self.resize(new_capacity);
        }
    }

是因为我们的存储接近当前总容量，所以reserve扩展了底层存储容量，还是为了减少探测长度，HashMap::resize被调用。这表示：

    #[inline(never)]
    #[cold]
    fn resize(&mut self, new_raw_cap: usize) {
        assert!(self.table.size() <= new_raw_cap);
        assert!(new_raw_cap.is_power_of_two() || new_raw_cap == 0);

        let mut old_table = replace(&mut self.table, 
        RawTable::new(new_raw_cap));
        let old_size = old_table.size();

        if old_table.size() == 0 {
            return;
        }

        let mut bucket = Bucket::head_bucket(&mut old_table);

        // This is how the buckets might be laid out in memory:
        // ($ marks an initialized bucket)
        //  ________________
        // |$$$_$$$$$$_$$$$$|
        //
        // But we've skipped the entire initial cluster of buckets
        // and will continue iteration in this order:
        //  ________________
        //     |$$$$$$_$$$$$
        //                  ^ wrap around once end is reached
        //  ________________
        //  $$$_____________|
        //    ^ exit once table.size == 0
        loop {
            bucket = match bucket.peek() {
                Full(bucket) => {
                    let h = bucket.hash();
                    let (b, k, v) = bucket.take();
                    self.insert_hashed_ordered(h, k, v);
                    if b.table().size() == 0 {
                        break;
                    }
                    b.into_bucket()
                }
                Empty(b) => b.into_bucket(),
            };
            bucket.next();
        }

        assert_eq!(self.table.size(), old_size);
    }

我们回到了RawTable，并且对名为Bucket的结构有了线索：

pub struct Bucket<K, V, M> {
    raw: RawBucket<K, V>,
    table: M,
}

好吧，我们在这里绕了一些圈子。桶参数化表是基于M而不是表持有一些桶的集合。RawBucket被描述为RawTable桶的不安全视图，其中有两个变体——EmptyBucket和FullBucket。这些变体用于填充BucketState枚举：

pub enum BucketState<K, V, M> {
    Empty(EmptyBucket<K, V, M>),
    Full(FullBucket<K, V, M>),
}

在这里，我们可以看到它在HashMap::insert_hashed_ordered中被使用：

    fn insert_hashed_ordered(&mut self, hash: SafeHash, k: K, v: V) {
        let mut buckets = Bucket::new(&mut self.table, hash);
        let start_index = buckets.index();

        loop {
            // We don't need to compare hashes for value swap.
            // Not even DIBs for Robin Hood.
            buckets = match buckets.peek() {
                Empty(empty) => {
                    empty.put(hash, k, v);
                    return;
                }
                Full(b) => b.into_bucket(),
            };
            buckets.next();
            debug_assert!(buckets.index() != start_index);
        }
    }

如果我们深入到empty.push(hash, k, v)，我们会发现以下内容：

    pub fn put(mut self, hash: SafeHash, key: K, value: V) 
        -> FullBucket<K, V, M> 
    {
        unsafe {
            *self.raw.hash() = hash.inspect();
            ptr::write(self.raw.pair(), (key, value));

            self.table.borrow_table_mut().size += 1;
        }

        FullBucket {
            raw: self.raw,
            table: self.table,
        }
    }

整洁。ptr::write(self.raw.pair(), (key, value))展示了我们正在使用由原始内存指针操作构建的结构，这对于将在关键路径中大量使用的结构来说很合适。self.raw.pair()返回将(key, value)移动到其中的适当偏移量，与我们已经熟悉的HashMap::insert移动语义相匹配。看看RawBucket的定义：

pub struct RawBucket<K, V> {
    hash_start: *mut HashUint,
    // We use *const to ensure covariance with respect to K and V
    pair_start: *const (K, V),
    idx: usize,
    _marker: marker::PhantomData<(K, V)>,
}

这里，我们有两个原始指针：hash_start和pair_start。前者是我们存储对哈希的第一个内存位置，后者是对的。这对数据在内存中是连续存储的，这正如你所期望的。表模块文档将这种方法称为未压缩数组。RawTable持有容量和数据，某种程度上。实际上，RawTable持有的数据被仔细地放置在内存中，正如我们所看到的，但没有所有者，正如 Rust 类型系统所理解的那样。这就是marker: marker::PhantomData<(K, V)>的作用。PhantomData指示编译器表现得好像RawTable<K, V>拥有(K, V)对，尽管由于我们正在进行的所有不安全指针操作，这实际上不能通过 Rust 来证明。我们可以通过检查确定RawTable通过RawTable::raw_bucket_at拥有其数据，因为它计算数据在内存中的位置：

    fn raw_bucket_at(&self, index: usize) -> RawBucket<K, V> {
        let hashes_size = self.capacity() * size_of::<HashUint>();
        let pairs_size = self.capacity() * size_of::<(K, V)>();

        let (pairs_offset, _, oflo) =
            calculate_offsets(hashes_size, pairs_size, 
                              align_of::<(K, V)>());
        debug_assert!(!oflo, "capacity overflow");

        let buffer = self.hashes.ptr() as *mut u8;
        unsafe {
            RawBucket {
                hash_start: buffer as *mut HashUint,
                pair_start: buffer.offset(pairs_offset as isize) 
                              as *const (K, V),
                idx: index,
                _marker: marker::PhantomData,
            }
        }
    }

好吧，通过检查和测试，正如您可以在模块底部看到的那样。

简单的 HashMap

我们还能如何实现 Rust 中的关联数组，它与标准库中的 HashMap 又将如何比较？显然，标准库的 HashMap 是巧妙的，它只存储足够的信息来减少从理想偏移量到总探测次数，通过在底层表的修改之间共享信息来实现。实际上，表模块中的注释断言，我们刚刚完成的设计与作为 Vec<Option<(u64, K, V)>> 结构的表相比要快得多——其中 u64 是键哈希，但可能仍然使用 Robin Hood 哈希和线性探测。如果我们做得更简单会怎样呢？我们将只支持两种操作——insert 和 lookup——以保持事情简单明了。我们还将保持与 HashMap 类似的大致类型约束，以便比较类似的事物。

开始一个新的 Rust 项目，命名为 naive_hashmap：

> cargo new naive_hashmap
     Created library `naive_hashmap` project

编辑 naive_hashmap/Cargo.toml 以看起来像这样：

[package]
name = "naive_hashmap"
version = "0.1.0"

[dependencies]
rand = "0.4.2"

[dev-dependencies]
quickcheck = "0.6"
criterion = "0.1"

[[bench]]
name = "naive"
harness = false

[[bin]]
name = "naive_interpreter"
doc = false

[[bin]]
name = "standard"
doc = false

[[bin]]
name = "naive"
doc = false

[[bench]]
name = "specialized"
harness = false

[[bin]]
name = "specialized_interpreter"
doc = false

[[bin]]
name = "specialized"
doc = false

目前不必过于担心一些开发依赖项，它们将在适当的时候解释。请注意，在接下来的讨论中，我们将在所有代码讨论之前对项目运行编译命令。如果您正在跟随书中预先编写的源代码，应该没有问题。如果您在书中进行编写，则需要注释掉目标。现在，打开 naive_hashmap/src/lib.rs 并添加以下前言：

#[cfg(test)]
extern crate quickcheck;

use std::hash::{BuildHasher, Hash, Hasher};
use std::borrow::Borrow;
use std::collections::hash_map::RandomState;
use std::{cmp, mem, ptr};

大多数 crate 根开始都有一个相当长的前言，naive_hashmap 也不例外。接下来是我们的 HashMap 结构：

#[derive(Default)]
pub struct HashMap<K, V, S = RandomState>
where
    K: Eq,
    V: ::std::fmt::Debug,
{
    hash_builder: S,
    data: Vec<(u64, K, V)>,
}

我们的简单 HashMap 与我们迄今为止看到的标准库 HashMap 有何不同？简单实现维护了参数化哈希器和类型约束，以及 V 实现的 Debug 特性约束，以便于调整。在底层结构方面，主要区别在于使用了 Vec——正如标准库 HashMap 的注释所指出的——但没有使用 Option 包装器。我们不实现删除操作，因此没有必要使用 Option，即使我们这样做，这个实现的计划也将完全依赖于 Vec::remove。Vec::remove 将移除索引右侧的所有元素向左移动的事实应该被充分理解。朋友们，这不会是一个快速的实现。现在：

impl<K: Eq, V> HashMap<K, V, RandomState>
where
    K: Eq + Hash,
    V: ::std::fmt::Debug,
{
    pub fn new() -> HashMap<K, V> {
        HashMap {
            hash_builder: RandomState::new(),
            data: Vec::new(),
        }
    }
}

fn make_hash<T: ?Sized, S>(hash_builder: &S, t: &T) -> u64
where
    T: Hash,
    S: BuildHasher,
{
    let mut state = hash_builder.build_hasher();
    t.hash(&mut state);
    state.finish()
}

impl<K, V, S> HashMap<K, V, S>
where
    K: Eq + Hash,
    S: BuildHasher,
    V: ::std::fmt::Debug,
{
    pub fn with_hasher(hash_builder: S) -> HashMap<K, V, S> {
        HashMap {
            hash_builder: hash_builder,
            data: Vec::new(),
        }
    }

我们的朴素实现在这里遵循标准库，实现了一个参数化为RandomState的HashMap——这样用户就不必考虑底层的哈希器——并且哈希器可以通过HashMap::with_hasher进行交换。Rust 团队选择以经过验证的密码学安全哈希算法来实现RandomState，这对于一个打算在公共互联网上使用的语言来说很合适。一些用户可能不会希望这个属性——而是选择一个更快、可能存在漏洞的哈希算法——并将RandomState替换为其他东西。我们的朴素HashMap保留了这种能力。

让我们检查我们的朴素HashMap的插入操作：

    pub fn insert(&mut self, k: K, v: V) -> Option<V> {
        let hash = make_hash(&self.hash_builder, &k);

        let end = self.data.len();
        for idx in 0..end {
            match self.data[idx].0.cmp(&hash) {
                cmp::Ordering::Greater => {
                    self.data.insert(idx, (hash, k, v));
                    return None;
                }
                cmp::Ordering::Less => continue,
                cmp::Ordering::Equal => {
                    let old = mem::replace(&mut self.data[idx].2, v);
                    return Some(old);
                }
            }
        }
        self.data.push((hash, k, v));
        None
    }

我们的朴素实现保持了标准库HashMap的 API，但仅此而已。键被哈希处理，然后在整个数据存储中进行线性搜索以找到满足以下两个条件之一的索引：

• 我们的新哈希值大于存储中的某个哈希值，在这种情况下，我们可以插入我们的键值对

• 我们的新哈希值等于存储中的某个哈希值，在这种情况下，我们可以替换现有的值

键值对按照它们的有序哈希值存储。插入的开销包括：

• 对键进行哈希处理

• 搜索插入索引，这是一个与存储的键值对数量成线性关系的操作

• 可能将内存中的键值对进行移位以适应存储中新的键

查找遵循类似的方案：

    pub fn get<Q: ?Sized>(&mut self, k: &Q) -> Option<&V>
    where
        K: Borrow<Q> + ::std::fmt::Debug,
        Q: Hash + Eq + ::std::fmt::Debug,
    {
        let hash = make_hash(&self.hash_builder, k);

        for &(bucket_hash, _, ref v) in &self.data {
            if hash == bucket_hash {
                return Some(v);
            }
        }
        None
    }

键被哈希处理，并在存储中进行针对该特定哈希值的线性搜索。在这里，我们只支付以下成本：

• 对键进行哈希处理

• 如果存在，搜索检索偏移量

在我们询问程序是否快速且正确之前，让我们花点时间考虑这一点。证明软件适用性的通常方式是通过单元测试，Rust 语言中直接内置了这种最小设置。单元测试是两个过程封装在一个方法中。当编写单元测试时，程序员将：

• 生成示例数据以测试软件中的某些代码路径

• 编写更多代码以证明当示例数据应用于测试的系统时，存在一个或多个期望的属性

这是一个很好的测试方法，用于证明被测试系统的“快乐路径”按预期工作。单元测试的弱点在于第一个过程，程序员必须非常努力地思考并生成一个示例数据集，以锻炼正确的代码路径，证明没有边缘情况，等等。人类在这方面做得不好，因为这项任务很繁琐，倾向于证明自己亲手制作的东西的功能，存在慢性盲点，或者其它原因。我们擅长做的是为我们的系统制定高级属性，这些属性必须始终成立或在特定情况下成立。幸运的是，对于程序员来说，计算机在执行繁琐、重复的任务以及为测试生成示例数据方面非常出色。

使用 QuickCheck 进行测试

考虑到这一点，在这本书中，我们将广泛使用基于属性的测试，某些文献也称之为生成性测试。基于属性的测试与单元测试有略微不同但相似的流程。当编写属性测试时，程序员将：

• 为被测试系统生成有效输入的方法

• 编写更多代码来证明对于所有有效的输入，系统的一个期望属性或属性始终成立

基于属性的测试在发现软件中的边缘情况方面非常出色，这些边缘情况是程序员可能没有想到的，或者，有时甚至不理解为潜在的问题。我们将使用 Andrew Gallant 的 QuickCheck，这是一个从 Haskell QuickCheck 模式而来的工具，由 Koen Claessen 和 John Hughes 在 2000 年的论文《QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs》中介绍。首先，一些前言，以便我们进入测试模块：

#[cfg(test)]
mod test {
    extern crate quickcheck;

    use super::*;
    use quickcheck::{Arbitrary, Gen, QuickCheck, TestResult};

如果我们要对我们的简单HashMap进行单元测试，我们可能会编写一个测试，在其中插入一个特定的任意键/值对，然后断言能够使用相同的键检索相同的值。这与基于属性的测试有何关联？属性是，如果我们对一个空的HashMap执行插入操作，键为k，值为v，然后立即检索k，我们将返回v。下面是具体做法：

    #[test]
    fn get_what_you_give() {
        fn property(k: u16, v: u16) -> TestResult {
            let mut system_under_test = HashMap::new();

            assert_eq!(None, system_under_test.insert(k, v));
            assert_eq!(Some(&v), system_under_test.get(&k));

            TestResult::passed()
        }
        QuickCheck::new().quickcheck(property as fn(u16, u16) -> 
                                     TestResult);
    }

测试名为get_what_you_give，并按照惯例用#[test]进行注释。不同之处在于这个测试有一个名为inner的属性函数，它编码了我们之前详细阐述的属性，并调用 QuickCheck 来实际运行属性测试，默认情况下 100 次，使用不同的输入。QuickCheck 如何管理这一点非常出色。根据 Claessen 和 Hughes 的论文，QuickCheck 为标准库中许多类型实现了Arbitrary特质。QuickCheck 定义Arbitrary如下，在quickcheck/src/arbitrary.rs中：

pub trait Arbitrary : Clone + Send + 'static {
    fn arbitrary<G: Gen>(g: &mut G) -> Self;

    fn shrink(&self) -> Box<Iterator<Item=Self>> {
        empty_shrinker()
    }
}

Gen 参数是 rand:Rng 的包装器，包含一些额外的机制来控制分布。这两个函数是 arbitrary 和 shrink。arbitrary 的作用很容易解释：它生成新的、随机的 Arbitrary 类型实例。shrink 函数稍微复杂一些。假设我们已生成一个接受 u16 向量的函数，但恰好有一个错误，如果向量中的某个成员是 0，它就会崩溃。QuickCheck 测试可能会找到这个问题，但第一个生成的任意向量可能有上千个成员和许多 0 条目。这不是一个非常有用的失败案例来开始诊断。一旦 QuickCheck 找到失败的案例，根据 Arbitrary::shrink 的定义，该案例将被收缩。我们的假设向量将被减半，如果新的案例也是失败的，那么它将再次减半，以此类推，直到它不再失败，此时——希望如此——我们的失败案例将是一个更有用的诊断工具。

由于宏的使用，u16 的 Arbitrary 实现有些复杂，但如果你眯起眼睛看，它就会变得清晰：

macro_rules! unsigned_arbitrary {
    ($($ty:tt),*) => {
        $(
            impl Arbitrary for $ty {
                fn arbitrary<G: Gen>(g: &mut G) -> $ty {
                    #![allow(trivial_numeric_casts)]
                    let s = g.size() as $ty;
                    use std::cmp::{min, max};
                    g.gen_range(0, max(1, min(s, $ty::max_value())))
                }
                fn shrink(&self) -> Box<Iterator<Item=$ty>> {
                    unsigned_shrinker!($ty);
                    shrinker::UnsignedShrinker::new(*self)
                }
            }
        )*
    }
}

unsigned_arbitrary! {
    usize, u8, u16, u32, u64
}

通过 unsigned_arbitrary! 生成任意实例，每个实例随后通过 unsigned_shrinker! 生成一个收缩器。这个宏太长了，无法在这里重印，但基本思路是在每次收缩时移除无符号整数的一半，直到达到零，此时放弃收缩。

在原始 QuickCheck 论文发表后的 15 年里，John Hughes 总结了他在接下来的 15 年中的经验，并在他的 2016 年论文 Experiences with QuickCheck: Testing the Hard Stuff and Staying Sane 中进行了总结。Hughes 指出，野外许多基于属性的测试并不生成原始类型。原始类型足够的应用领域往往是代码库中那些罕见的、受祝福的纯函数。相反，由于程序中的许多函数本质上是状态性的，基于属性的测试倾向于生成对状态系统的任意 动作，模拟 预期的行为，并验证被测试的系统是否按照其模型行为。

这如何应用到我们的天真 HashMap 上？被测试的系统是天真 HashMap，这很清楚。我们的动作是：

• INSERT 键值

• LOOKUP 键

希望这很简单。那么模型呢？在这个特定的情况下，我们很幸运。我们的模型已经为我们编写好了：标准库的 HashMap。我们只需要确认，如果将相同的动作按相同的顺序应用到我们的天真 HashMap 和标准 HashMap 上，那么模型和被测试系统将得到相同的返回值。这看起来如何？首先，我们需要动作：

    #[derive(Clone, Debug)]
    enum Action<T>
    where
        T: Arbitrary,
    {
        Insert(T, u16),
        Lookup(T),
    }

我们的Action<T>在T: Arbitrary上参数化，并且所有通过插入操作传递的值都被标记为u16。这样做主要是为了方便。键和值可以是任意类型或具体类型，具体取决于测试者的偏好。我们的Arbitrary定义如下：

    impl<T> Arbitrary for Action<T>
    where
        T: Arbitrary,
    {
        fn arbitrary<G>(g: &mut G) -> Action<T>
        where
            G: Gen,
        {
            let i: usize = g.gen_range(0, 100);
            match i {
                0...50 => Action::Insert(Arbitrary::arbitrary(g), 
                                         u16::arbitrary(g)),
                _ => Action::Lookup(Arbitrary::arbitrary(g)),
            }
        }
    }

任何操作发生的可能性都是相同的，并且T或u16的任何实例都可以用于。我们对原始HashMap与标准库中的HashMap的验证：

    #[test]
    fn sut_vs_genuine_article() {
        fn property<T>(actions: Vec<Action<T>>) -> TestResult
        where
            T: Arbitrary + Eq + Hash + ::std::fmt::Debug,
        {
            let mut model = ::std::collections::HashMap::new();
            let mut system_under_test = HashMap::new();

            for action in actions.into_iter() {
                match action {
                    Action::Insert(k, v) => {
                        assert_eq!(model.insert(k.clone(), v), 
                        system_under_test.insert(k, v));
                    }
                    Action::Lookup(k) => {
                        assert_eq!(model.get(&k), 
                        system_under_test.get(&k));
                    }
                }
            }
            TestResult::passed()
        }
        QuickCheck::new().quickcheck(property as fn(Vec<Action<u8>>) -> 
                                     TestResult);
    }
}

希望这看起来与我们的先前的 QuickCheck 测试相似。再次强调，我们有一个内部属性函数执行实际工作，并要求 QuickCheck 在任意的Action<u8>向量上运行这个属性测试。对于向量中存在的每个操作，我们将它们应用于模型和被测试的系统，验证结果是否相同。这里故意选择了u8类型，而不是像u64这样的大域类型。编写 QuickCheck 测试的一个关键挑战是探测极端不可能发生的事件。QuickCheck 是盲目的，因为如果某个路径是最可能被选择的路径，那么每次运行都可能会选择相同的路径。虽然数百万的 QuickCheck 测试可以提供对用途适用性的高信心，但运行的无视性质意味着 QuickCheck 也应该与称为模糊测试器的工具一起使用。这些工具不会检查程序的正确功能与模型是否一致。相反，它们的唯一目的是验证程序崩溃的缺失。

使用美国模糊跳蚤进行测试

在这本书中，我们将使用美国模糊跳蚤（American Fuzzy Lop），这是一种在其他系统语言中广泛使用的最佳模糊测试工具。AFL 是一个外部工具，它接受输入数据集、从STDIN读取输入的可执行文件，并使用各种启发式方法对数据集进行变异以找到崩溃的输入。我们的目标是寻找原始HashMap中的崩溃错误，这意味着我们需要某种程序来运行我们的HashMap。实际上，如果你还记得项目的Cargo.toml文件，我们已经为此建立了基础设施：

[[bin]]
name = "naive_interpreter"
doc = false

naive_interpreter的源代码看起来有点古怪，但除此之外并无异常：

extern crate naive_hashmap;

use std::io;
use std::io::prelude::*;

fn main() {
    let mut hash_map = naive_hashmap::HashMap::new();

    let n = io::stdin();
    for line in n.lock().lines() {
        if let Ok(line) = line {
            let mut cmd = line.split(" ");
            match cmd.next() {
                Some("LOOKUP") => {
                    if let Some(key) = cmd.next() {
                        let _ = hash_map.get(key);
                    } else {
                        continue;
                    }
                }
                Some("INSERT") => {
                    if let Some(key) = cmd.next() {
                        if let Some(val) = cmd.next() {
                            let _ = hash_map.insert(key.to_string(), 
                            val.to_string());
                        }
                    } else {
                        continue;
                    }
                }
                _ => continue,
            }
        } else {
            break;
        }
    }
}

行从stdin读取，这些行沿空格分割并解释为命令，要么是LOOKUP要么是INSERT，这些命令被解释为对原始HashMap的操作。AFL 运行的数据集可以几乎存储在任何地方。按照惯例，在这本书中，我们将数据集存储在项目的顶层resources/directory目录中。这里是resources/in/mixed_gets_puts：

LOOKUP 10
INSERT abs 10
LOOKUP abs

您的输入语料库越大，AFL 可以变异的材料就越多，也许您会发现崩溃的漏洞越快。即使在像简单的HashMap这样的情况下，我们可以合理地确信不会有崩溃的漏洞——由于缺乏指针操作和可能致命的整数运算——建立良好的语料库来支持未来的努力也是值得的。在构建项目的发布版本后，启动 AFL 运行只需一个 cargo 命令：

> cargo afl build --release
> cargo afl fuzz -i resources/in/ -o resources/out/ target/release/naive_interpreter

这表示在 AFL 下执行target/release/naive_interpreter，输入语料库位于resources/in，并将任何失败的案例输出到resources/out。这样的崩溃通常是非常好的单元测试。现在，模糊工具的一般技巧是它们不是任何快速循环测试驱动开发循环的一部分。这些工具运行时间很长，通常在专用硬件上过夜或持续多天。例如，这是我在编写本章时进行的 AFL 运行：

这里有很多信息，但请考虑 AFL 运行时指标是以天为单位的。与其他模糊器相比，使用 AFL 的一个关键优势是 AFL 在安全社区中的突出地位。有许多论文描述了其实现及其，嗯，全面的接口。强烈建议您浏览本章的进一步阅读部分以获取更多信息。

使用 Criterion 进行性能测试

我们现在可以相当有信心，我们简单的HashMap在已检查的属性上与标准库具有相同的行为。但简单的HashMap的运行时性能如何？为了回答这个问题，我们将编写一个基准测试，但不是使用夜间渠道中可用的不稳定 Bencher 子系统编写的基准测试。相反，我们将使用 Jorge Aparicio 的 criterion——受 Bryan O'Sullivan 同名的 Haskell 工具的启发——它可在稳定版上使用，并进行了统计上有效的运行采样。所有 Rust 基准测试代码都位于顶级benches/目录下，criterion 基准测试也不例外。打开benches/naive.rs并给它这个前言：

#[macro_use]
extern crate criterion;
extern crate naive_hashmap;
extern crate rand;

use criterion::{Criterion, Fun};
use rand::{Rng, SeedableRng, XorShiftRng};

这个基准测试通过伪随机性产生有趣的运行。与单元测试类似，基准测试中的手工数据集往往会倾向于作者的某些隐含偏见，从而损害基准测试。除非，当然，手工数据集正是所需的。编写良好的基准测试程序是一项相当繁重的工作。我们使用的Rng是XorShift，这是一种以速度著称的伪随机生成器，其加密安全性较低。这符合我们的需求：

fn insert_and_lookup_naive(mut n: u64) {
    let mut rng: XorShiftRng = SeedableRng::from_seed([1981, 1986,
                                                       2003, 2011]);
    let mut hash_map = naive_hashmap::HashMap::new();

    while n != 0 {
        let key = rng.gen::<u8>();
        if rng.gen::<bool>() {
            let value = rng.gen::<u32>();
            hash_map.insert(key, value);
        } else {
            hash_map.get(&key);
        }
        n -= 1;
    }
}

第一个基准测试，命名为 insert_and_lookup_native，对原始的 HashMap 进行了伪随机的插入和查找操作。细心阅读的读者会注意到，XorShiftRng 在每个基准测试中都使用了相同的种子。这很重要。虽然我们希望避免手动制作基准测试数据集，但我们确实希望每次运行时数据集都是相同的，否则基准测试比较就没有依据。值得注意的是，基准测试的其余部分不应该有太多惊喜。生成随机操作，应用它们，等等。由于我们对标准库中的 HashMap 的时间感兴趣，因此我们也为它创建了一个基准测试：

fn insert_and_lookup_standard(mut n: u64) {
    let mut rng: XorShiftRng = SeedableRng::from_seed([1981, 1986, 
                                                       2003, 2011]);
    let mut hash_map = ::std::collections::HashMap::new();

    while n != 0 {
        let key = rng.gen::<u8>();
        if rng.gen::<bool>() {
            let value = rng.gen::<u32>();
            hash_map.insert(key, value);
        } else {
            hash_map.get(&key);
        }
        n -= 1;
    }
}

在撰写本书时，Criterion 提供了一种比较两个函数的方法，或者比较一个在参数化输入上运行的函数，但不同时比较两者。这在我们这里是个问题，因为我们想比较多个输入上的两个函数。为此，这个基准测试依赖于一个名为 insert_lookup! 的小宏：

macro_rules! insert_lookup {
    ($fn:ident, $s:expr) => {
        fn $fn(c: &mut Criterion) {
            let naive = Fun::new("naive", |b, i| b.iter(||                   
                                   insert_and_lookup_naive(*i))
            );
            let standard = Fun::new("standard", |b, i| b.iter(|| 
                                      insert_and_lookup_standard(*i))
            );

            let functions = vec![naive, standard];

            c.bench_functions(&format!("HashMap/{}", $s),
                              functions, &$s);
        }
    }
}

insert_lookup!(insert_lookup_100000, 100_000);
insert_lookup!(insert_lookup_10000, 10_000);
insert_lookup!(insert_lookup_1000, 1_000);
insert_lookup!(insert_lookup_100, 100);
insert_lookup!(insert_lookup_10, 10);
insert_lookup!(insert_lookup_1, 1);

这里关键是，我们创建了两个用于比较的 Fun，分别称为 naive 和 standard，然后使用 Criterion::bench_functions 运行两个之间的比较。在宏的调用中，我们评估 insert_and_lookup_* 从 1 到 100_000，这是对标准和原始 HashMap 进行插入操作的总数。最后，我们需要设置 criterion 组和主函数：

criterion_group!{
    name = benches;
    config = Criterion::default();
    targets = insert_lookup_100000, insert_lookup_10000, 
              insert_lookup_1000, insert_lookup_100, 
              insert_lookup_10, insert_lookup_1
}
criterion_main!(benches);

运行 criterion 基准测试与执行 Rust 内置基准测试没有区别：

> cargo bench
   Compiling naive_hashmap v0.1.0 (file:///home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/naive_hashmap)
    Finished release [optimized] target(s) in 5.26 secs
     Running target/release/deps/naive_hashmap-fe6fcaf7cf309bb8

running 2 tests
test test::get_what_you_give ... ignored
test test::sut_vs_genuine_article ... ignored

test result: ok. 0 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out

     Running target/release/deps/naive_interpreter-26c60c76389fd26d

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/release/deps/naive-96230b57fe0068b7
HashMap/100000/naive    time:   [15.807 ms 15.840 ms 15.879 ms]
Found 13 outliers among 100 measurements (13.00%)
  2 (2.00%) low mild
  1 (1.00%) high mild
  10 (10.00%) high severe
HashMap/100000/standard time:   [2.9067 ms 2.9102 ms 2.9135 ms]
Found 7 outliers among 100 measurements (7.00%)
  1 (1.00%) low severe
  5 (5.00%) low mild
  1 (1.00%) high mild

HashMap/10000/naive     time:   [1.5475 ms 1.5481 ms 1.5486 ms]
Found 9 outliers among 100 measurements (9.00%)
  1 (1.00%) low severe
  2 (2.00%) high mild
  6 (6.00%) high severe
HashMap/10000/standard  time:   [310.60 us 310.81 us 311.03 us]
Found 11 outliers among 100 measurements (11.00%)
  1 (1.00%) low severe
  2 (2.00%) low mild
  3 (3.00%) high mild
  5 (5.00%) high severe

以此类推。如果基准测试系统中安装了 gnuplot，Criterion 还会友好地生成你的运行时 gnuplot 图形。这强烈推荐。

使用 Valgrind 套件进行检查

您的特定基准测试输出可能会有所不同，但很明显，原始实现并不快。我们有哪些工具可用来诊断我们代码的问题，引导我们找到优化的热点，或者帮助我们确信需要更好的算法？现在，我们将离开 Rust 特定工具的领域，深入到系统程序员熟悉的工具。如果您不熟悉它们，那也没关系——我们将描述它们的使用方法，并且对于有志于阅读的读者来说，有大量的外部材料可用。好吧，首先，我们需要一些程序来测试我们的原始 HashMap 和标准 HashMap。naive_interpreter 可以工作，但它做了很多额外的操作，这可能会使问题复杂化。为此，为了检验目的，我们需要两个程序，一个用于建立基线，一个用于我们的实现。我们的基线，称为 bin/standard.rs：

extern crate naive_hashmap;
extern crate rand;

use std::collections::HashMap;
use rand::{Rng, SeedableRng, XorShiftRng};

fn main() {
    let mut rng: XorShiftRng = SeedableRng::from_seed([1981, 1986, 
                                                       2003, 2011]);
    let mut hash_map = HashMap::new();

    let mut insert_empty = 0;
    let mut insert_present = 0;
    let mut get_fail = 0;
    let mut get_success = 0;

    for _ in 0..100_000 {
        let key = rng.gen::<u16>();
        if rng.gen::<bool>() {
            let value = rng.gen::<u32>();
            if hash_map.insert(key, value).is_none() {
                insert_empty += 1;
            } else {
                insert_present += 1;
            }
        } else {
            if hash_map.get(&key).is_none() {
                get_fail += 1;
            } else {
                get_success += 1;
            }
        }
    }

    println!("INSERT");
    println!("  empty:   {}", insert_empty);
    println!("  present: {}", insert_present);
    println!("LOOKUP");
    println!("  fail:    {}", get_fail);
    println!("  success: {}", get_success);
}

我们的测试文章程序与之前完全相同，只是前言略有不同：

extern crate naive_hashmap;
extern crate rand;

use naive_hashmap::HashMap;
use rand::{Rng, SeedableRng, XorShiftRng};

fn main() {
    let mut rng: XorShiftRng = SeedableRng::from_seed([1981, 1986, 
                                                       2003, 2011]);
    let mut hash_map = HashMap::new();

    let mut insert_empty = 0;
    let mut insert_present = 0;
    let mut get_fail = 0;
    let mut get_success = 0;

    for _ in 0..100_000 {
        let key = rng.gen::<u16>();
        if rng.gen::<bool>() {
            let value = rng.gen::<u32>();
            if hash_map.insert(key, value).is_none() {
                insert_empty += 1;
            } else {
                insert_present += 1;
            }
        } else {
            if hash_map.get(&key).is_none() {
                get_fail += 1;
            } else {
                get_success += 1;
            }
        }
    }

    println!("INSERT");
    println!("  empty:   {}", insert_empty);
    println!("  present: {}", insert_present);
    println!("LOOKUP");
    println!("  fail:    {}", get_fail);
    println!("  success: {}", get_success);
}

这很容易，与之前探索的基准测试代码精神相似。现在，让我们设置基线。首先，内存分配：

naive_hashmap > valgrind --tool=memcheck target/release/standard
==13285== Memcheck, a memory error detector
==13285== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==13285== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==13285== Command: target/release/standard
==13285==
INSERT
  empty:   35217
  present: 15071
LOOKUP
  fail:    34551
  success: 15161
==13285==
==13285== HEAP SUMMARY:
==13285==     in use at exit: 0 bytes in 0 blocks
==13285==   total heap usage: 7 allocs, 7 frees, 2,032 bytes allocated
==13285==
==13285== All heap blocks were freed -- no leaks are possible
==13285==
==13285== For counts of detected and suppressed errors, rerun with: -v
==13285== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

总共分配了七个内存块，释放了七个内存块，总共分配了 2,032 字节。对原始的 memcheck 运行结果相同：

==13307== HEAP SUMMARY:
==13307==     in use at exit: 0 bytes in 0 blocks
==13307==   total heap usage: 7 allocs, 7 frees, 2,032 bytes allocated

原始运行速度明显较慢，所以不是分配内存让我们陷入困境。由于这些程序分配的内存如此之少，我们将跳过 Valgrind massif——它不太可能发现任何有用的信息。Valgrind cachegrind 应该很有趣。以下是基线：

naive_hashmap > valgrind --tool=cachegrind --branch-sim=yes target/release/standard
==13372== Cachegrind, a cache and branch-prediction profiler
==13372== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al.
==13372== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==13372== Command: target/release/standard
==13372==
--13372-- warning: L3 cache found, using its data for the LL simulation.
INSERT
  empty:   35217
  present: 15071
LOOKUP
  fail:    34551
  success: 15161
==13372==
==13372== I   refs:      25,733,614
==13372== I1  misses:         2,454
==13372== LLi misses:         2,158
==13372== I1  miss rate:       0.01%
==13372== LLi miss rate:       0.01%
==13372==
==13372== D   refs:       5,400,581  (2,774,345 rd   + 2,626,236 wr)
==13372== D1  misses:       273,218  (  219,462 rd   +    53,756 wr)
==13372== LLd misses:        36,267  (    2,162 rd   +    34,105 wr)
==13372== D1  miss rate:        5.1% (      7.9%     +       2.0%  )
==13372== LLd miss rate:        0.7% (      0.1%     +       1.3%  )
==13372==
==13372== LL refs:          275,672  (  221,916 rd   +    53,756 wr)
==13372== LL misses:         38,425  (    4,320 rd   +    34,105 wr)
==13372== LL miss rate:         0.1% (      0.0%     +       1.3%  )
==13372==
==13372== Branches:       3,008,198  (3,006,105 cond +     2,093 ind)
==13372== Mispredicts:      315,772  (  315,198 cond +       574 ind)
==13372== Mispred rate:        10.5% (     10.5%     +      27.4%   )

让我们分拆一下：

==13372== I   refs:      25,733,614
==13372== I1  misses:         2,454
==13372== LLi misses:         2,158
==13372== I1  miss rate:       0.01%
==13372== LLi miss rate:       0.01%

第一部分详细说明了我们的指令缓存行为。I refs: 25,733,614告诉我们标准程序总共执行了 25,733,614 条指令。这通常是在密切相关实现之间进行比较的有用方法，正如我们稍后将看到的那样。回想一下，cachegrind 模拟了一个具有两级指令和数据缓存的机器，第一级缓存被称为I1或D1（指令或数据缓存），最后一级缓存以LL开头。在这里，我们看到第一级和最后一级指令缓存在我们的 2,500 万条指令运行中各自缺失了大约 2,500 次。这与我们的程序如此之小相符。第二部分如下：

==13372== D   refs:       5,400,581  (2,774,345 rd   + 2,626,236 wr)
==13372== D1  misses:       273,218  (  219,462 rd   +    53,756 wr)
==13372== LLd misses:        36,267  (    2,162 rd   +    34,105 wr)
==13372== D1  miss rate:        5.1% (      7.9%     +       2.0%  )
==13372== LLd miss rate:        0.7% (      0.1%     +       1.3%  )

这是数据缓存行为，分为之前讨论的两个缓存层，并进一步细分为读取和写入。第一行告诉我们，总共对缓存进行了 5,400,581 次读取和写入，其中 2,774,345 次读取和 2,626,236 次写入。然后这些总数进一步按第一级和最后一级缓存进行划分。这里我们发现标准库的HashMap表现很好，D1缺失率为 5.1%，LLd缺失率为 0.7%。最后一个百分比是关键：它越高，我们的程序访问主内存的次数就越多。如您在第一章，“预备知识——机器架构和 Rust 入门”中回忆的那样，这样做会非常慢。第三部分如下：

==13372== LL refs:          275,672  (  221,916 rd   +    53,756 wr)
==13372== LL misses:         38,425  (    4,320 rd   +    34,105 wr)
==13372== LL miss rate:         0.1% (      0.0%     +       1.3%  )

这侧重于数据缓存和指令缓存访问 LL 缓存的组合行为。就我个人而言，我并不经常发现这一部分与之前讨论的部分相比有启发。您的体验可能会有所不同。最后一部分如下：

==13372== Branches:       3,008,198  (3,006,105 cond +     2,093 ind)
==13372== Mispredicts:      315,772  (  315,198 cond +       574 ind)
==13372== Mispred rate:        10.5% (     10.5%     +      27.4%   )

这详细说明了我们程序的分支预测错误行为。在运行程序中，我们通过广泛的分支来淹没标准库的HashMap，但这仍然有助于建立某种基线。第一行告诉我们，在执行过程中共进行了 3,008,198 次分支。其中大多数——3,006,105 次——是条件分支，即基于某些条件的跳转。这与我们在运行程序中的条件语句数量相符。少数分支是间接的，意味着它们根据先前指令的结果跳转到内存中的偏移量。总的来说，我们的分支预测错误率是 10.5%。

好吧，原始的HashMap实现表现如何？

naive_hashmap > valgrind --tool=cachegrind --branch-sim=yes target/release/naive
==13439== Cachegrind, a cache and branch-prediction profiler
==13439== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al.
==13439== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==13439== Command: target/release/naive
==13439==
--13439-- warning: L3 cache found, using its data for the LL simulation.
INSERT
  empty:   35217
  present: 15071
LOOKUP
  fail:    34551
  success: 15161
==13439==
==13439== I   refs:      15,385,395,657
==13439== I1  misses:             2,376
==13439== LLi misses:             2,157
==13439== I1  miss rate:           0.00%
==13439== LLi miss rate:           0.00%
==13439==
==13439== D   refs:       1,609,901,359  (1,453,944,896 rd   + 155,956,463 wr)
==13439== D1  misses:       398,465,518  (  398,334,276 rd   +     131,242 wr)
==13439== LLd misses:            12,647  (        2,153 rd   +      10,494 wr)
==13439== D1  miss rate:           24.8% (         27.4%     +         0.1%  )
==13439== LLd miss rate:            0.0% (          0.0%     +         0.0%  )
==13439==
==13439== LL refs:          398,467,894  (  398,336,652 rd   +     131,242 wr)
==13439== LL misses:             14,804  (        4,310 rd   +      10,494 wr)
==13439== LL miss rate:             0.0% (          0.0%     +         0.0%  )
==13439==
==13439== Branches:       4,430,578,248  (4,430,540,970 cond +      37,278 ind)
==13439== Mispredicts:          193,192  (      192,618 cond +         574 ind)
==13439== Mispred rate:             0.0% (          0.0%     +         1.5%   )

已经有一些突出的地方。首先，简单实现执行了 15,385,395,657 条指令，而基准值只有 25,733,614 条。简单实现实际上比标准库做了多得多的工作。在这个阶段，不查看任何进一步的数据，合理地得出结论：正在检查的程序存在根本性的缺陷：需要重新思考算法。任何微优化都无法解决这个问题。但是，这一点是事先就理解的；这也是为什么程序一开始就被称作“简单”的原因。第二个主要关注点是，D1缓存的未命中率比基准值高出近 20%，不容忽视的是，与基准值相比，对第一级缓存的读写操作要多得多。奇怪的是，与基准值相比，简单实现受LLd缓存未命中的影响更小——10,494 比 34,105。这里没有假设。跳过分支预测部分，我们发现简单实现保持了主题，并且比标准实现执行了更多的分支，但总的误预测数量较少。这与以线性查找和比较为主的算法相吻合，正如简单实现一样。

使用 Linux perf 进行检测

值得注意的是，Valgrind 的 cachegrind 是一个模拟。如果你有 Linux 系统的访问权限，可以使用 perf 工具获取关于程序缓存性能的真正、真实的数据以及更多。这非常推荐，并且我们将在整本书中这样做。像 git 一样，perf 是一个带有自己子命令和各自选项的工具集——perf。

这是一个值得阅读文档的工具。无论如何，在 perf 下标准看起来是什么样的？

naive_hashmap > perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses target/release/standard > /dev/null

 Performance counter stats for 'target/release/standard':

      6.923765      task-clock (msec)         #    0.948 CPUs utilized
             0      context-switches          #    0.000 K/sec
           633      page-faults               #    0.091 M/sec
    19,703,427      cycles                    #    2.846 GHz
    26,234,708      instructions              #    1.33  insn per cycle
     2,802,334      branches                  #  404.741 M/sec
      290,475      branch-misses             #   10.37% of all branches
       635,526      cache-references          #   91.789 M/sec
     67,304      cache-misses              # 10.590 % of all cache refs

       0.007301775 seconds time elapsed

简单实现的效果如何？

naive_hashmap > perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses target/release/naive > /dev/null

 Performance counter stats for 'target/release/naive':

    1323.724713      task-clock (msec)         #    1.000 CPUs utilized
              1      context-switches          #    0.001 K/sec
            254      page-faults               #    0.192 K/sec
  3,953,955,131      cycles                    #    2.987 GHz 15,390,499,356      instructions               #  3.89  insn per cycle    4,428,637,974      branches                    # 3345.588 M/sec
      204,132      branch-misses               #  0.00% of all branches
    455,719,875      cache-references          #  344.271 M/sec
   21,311      cache-misses                 # 0.005 % of all cache refs

       1.324163884 seconds time elapsed

这与 Valgrind 模拟的结果相当吻合，并得出相同的结论：插入的工作量过多。分支过多，指令过多，经验丰富的读者会提前看到这一点，但能够将已知的事物用数字表示出来是值得的。

更好的简单 HashMap

我们如何比简单实现做得更好？显然，有算法改进的空间——我们可以实现任何类型的探测——但如果我们要与标准库的 HashMap 竞争，那么我们很可能有特定的原因。特定的原因意味着我们对我们知道的数据有独特的了解，或者愿意做出一般数据结构无法做出的权衡。广泛地说，在构建接近机器性能极限的软件时，应该有以下主要目标：

1. 改进底层算法，减少总工作量。

2. 提高数据访问的缓存局部性。这可能意味着：

   1. 保持你的工作集在 L1 缓存中

   2. 压缩你的数据以更好地适应缓存。

3. 避免分支预测。这可能意味着：

   1. 在可能的情况下完全消除分支

   2. 限制你分支的概率分布。

这如何应用到我们这里呢？好吧，假设我们知道对于我们的应用程序K == u8，但我们仍然有一个不受约束的V。u8是一个基数低的键，我们应该能够通过牺牲一点内存来为u8键构建一个更快的结构。不幸的是，Rust 在稳定渠道中还没有类型特殊化。类型特殊化对于在不破坏抽象的情况下生产高性能软件非常重要。它允许程序员定义一个抽象接口和实现，然后在以后，将一些参数化类型专门化为具有特殊目的的实现的具体形式。Rust RFC 1210 (github.com/rust-lang/rfcs/pull/1210/files#diff-b652f1feca90247198ee29514ac22cf3)详细说明了 Rust 中的特殊化将如何工作，Rust PR 31844 (github.com/rust-lang/rust/issues/31844)跟踪了正在进行的实现，也就是说，所有这些都只暴露在 nightly 版本中。这一章坚持使用稳定版本，因此，不幸的是，我们将需要创建一个新的 HashMap 而不是进行特殊化。鼓励读者亲自尝试特殊化。这相当不错。

我们将HashMapU8实现放在naive_hashmap/src/lib.rs中。实现相当小：

pub struct HashMapU8<V>
where
    V: ::std::fmt::Debug,
{
    data: [Option<V>; 256],
}

impl<V> HashMapU8<V>
where
    V: ::std::fmt::Debug,
{
    pub fn new() -> HashMapU8<V> {
        let data = unsafe {
            let mut data: [Option<V>; 256] = mem::uninitialized();
            for element in data.iter_mut() {
                ptr::write(element, None)
            }
            data
        };
        HashMapU8 { data: data }
    }

    pub fn insert(&mut self, k: u8, v: V) -> Option<V> {
        mem::replace(&mut self.data[(k as usize)], Some(v))
    }

    pub fn get(&mut self, k: &u8) -> Option<&V> {
        let val = unsafe { self.data.get_unchecked((*k as usize)) };
        val.as_ref()
    }
}

这里的想法很简单——u8是一种具有如此基数的数据类型，我们可以将每个可能的键重新组合成一个数组偏移量。每个键的值是一个Option<V>，如果没有为键设置过值，则为None，否则为Some。不需要进行哈希处理，并且在没有特殊化处理的情况下，我们放弃了该类型的要求。每个HashMapU8将保留256 * ::core::mem::size_of::<Option<V>>()字节。鉴于这个实现中存在不安全代码，进行一次 AFL 运行以搜索崩溃是值得的。专门化映射的解释器与原始解释器类似，只是我们现在注意解析u8键：

extern crate naive_hashmap;

use std::io;
use std::io::prelude::*;
use std::str::FromStr;

fn main() {
    let mut hash_map = naive_hashmap::HashMapU8::new();

    let n = io::stdin();
    for line in n.lock().lines() {
        if let Ok(line) = line {
            let mut cmd = line.split(" ");
            match cmd.next() {
                Some("LOOKUP") => {
                    if let Some(key) = cmd.next() {
                        if let Ok(key) = u8::from_str(key) {
                            let _ = hash_map.get(&key);
                        } else {
                            continue;
                        }
                    } else {
                        continue;
                    }
                }
                Some("INSERT") => {
                    if let Some(key) = cmd.next() {
                        if let Ok(key) = u8::from_str(key) {
                            if let Some(val) = cmd.next() {
                          let _ = hash_map.insert(key, 
                           val.to_string());
                            } else {
                                continue;
                            }
                        }
                    } else {
                        continue;
                    }
                }
                _ => continue,
            }
        } else {
            break;
        }
    }
}

我将省略 AFL 输出，但作为提醒，以下是运行专门解释器的方法：

> cargo afl build --release
> cargo afl fuzz -i resources/in/ -o resources/out/ target/release/specialized_interpreter

生成标准基准测试的方法将与原始实现的方法非常相似，只是我们会在这里和那里替换一些名称。我们将跳过列出代码，希望你能按照自己的需求进行复现。然而，结果是有希望的：

HashMap/100000/speciali time:   [662.01 us 665.28 us 668.44 us]
HashMap/100000/standard time:   [2.3471 ms 2.3521 ms 2.3583 ms]

HashMap/10000/specializ time:   [64.294 us 64.440 us 64.576 us]
HashMap/10000/standard  time:   [253.14 us 253.31 us 253.49 us]

与之前的naive.rs和standard.rs类似，我们还有一个specialized.rs运行器，为了避免重复，我们在这里将不列出。让我们通过 Valgrind cachegrind 运行专门化：

naive_hashmap > valgrind --tool=cachegrind --branch-sim=yes target/release/specialized
==24235== Cachegrind, a cache and branch-prediction profiler
==24235== Copyright (C) 2002-2015, and GNU GPL'd, by Nicholas Nethercote et al.
==24235== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==24235== Command: target/release/specialized
==24235==
--24235-- warning: L3 cache found, using its data for the LL simulation.
INSERT
  empty:   256
  present: 50032
LOOKUP
  fail:    199
  success: 49513
==24235==
==24235== I   refs:      5,200,051
==24235== I1  misses:        2,248
==24235== LLi misses:        2,068
==24235== I1  miss rate:      0.04%
==24235== LLi miss rate:      0.04%
==24235==
==24235== D   refs:        443,562  (233,633 rd   + 209,929 wr)
==24235== D1  misses:        4,736  (  3,249 rd   +   1,487 wr)
==24235== LLd misses:        3,512  (  2,112 rd   +   1,400 wr)
==24235== D1  miss rate:       1.1% (    1.4%     +     0.7%  )
==24235== LLd miss rate:       0.8% (    0.9%     +     0.7%  )
==24235==
==24235== LL refs:           6,984  (  5,497 rd   +   1,487 wr)
==24235== LL misses:         5,580  (  4,180 rd   +   1,400 wr)
==24235== LL miss rate:        0.1% (    0.1%     +     0.7%  )
==24235==
==24235== Branches:        393,599  (391,453 cond +   2,146 ind)
==24235== Mispredicts:      57,380  ( 56,657 cond +     723 ind)
==24235== Mispred rate:       14.6% (   14.5%     +    33.7%   )

与标准的valgrind运行相比，我们执行的总指令数大约是 1/5，并且D1和LLd缺失的数量也显著减少。这并不奇怪。我们的HashMapU8的哈希是一个极其便宜的指针偏移量，存储的大小将舒适地适应缓存。Linux perf 也有类似的故事：

naive_hashmap > perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses target/release/specialized > /dev/null

 Performance counter stats for 'target/release/specialized':

     1.433884      task-clock (msec)         #    0.788 CPUs utilized
            0      context-switches          #    0.000 K/sec
          104      page-faults               #    0.073 M/sec
    4,138,436      cycles                    #    2.886 GHz
    6,141,529      instructions              #    1.48  insn per cycle
      749,155      branches                  #  522.466 M/sec
       59,914      branch-misses             #    8.00% of all branches
       74,760      cache-references          #   52.138 M/sec

       0.001818537 seconds time elapsed

呼吸！让我们总结一下我们的努力：

名称	任务时钟（毫秒）	指令	分支	分支缺失	缓存引用	缓存缺失
专用	1.433884	6,141,529	749,155	59,914	74,760	n/a
标准	6.923765	26,234,708	2,802,334	290,475	635,526	67,304
原始	1323.724713	15,390,499,356	4,428,637,974	204,132	455,719,875	21,311

摘要

我们应该从所有这些中理解什么？为了生产能够在机器能力边缘运行的软件，你必须理解一些重要的事情。首先，如果你没有测量你的程序，你只是在猜测。像 criterion 那样测量运行时间是很重要的，但这是一个粗略的洞察。我的程序在哪里花费了时间？ 是 Valgrind 套件和 perf 可以回答的问题，但你必须要有基准来为你的问题提供上下文。测量然后验证行为也是这项工作的重要部分，这就是为什么我们在 QuickCheck 和 AFL 上花费了这么多时间。其次，有一个目标在心中。在本章中，我们将标准库HashMap的速度作为我们的目标，但在实际的代码库中，总会有需要抛光和改进的地方。重要的是要知道需要做什么来解决当前的问题，这将告诉你你的时间需要花在哪里。第三，了解你的机器。现代的超标量、并行机器编程很奇怪，如果不考虑它们的行为，理解你的程序为什么会以这种方式运行将会很困难。最后，算法是最重要的。我们的原始HashMap未能良好地执行，因为我们为每次插入执行平均 O(n/2)操作的想法是错误的，我们在实践中证明了这一点。标准库的HashMap是一个基于线性探测的通用结构，很明显，在使其适用于各种情况时投入了大量的思考。当你的程序运行得太慢时，与其进行微优化，不如退一步考虑问题空间。是否有更好的算法可用，是否有关于数据的洞察可以用来将算法转向其他方向？

这就是性能工作的精髓。在我看来，相当令人满意。

进一步阅读

在本章中，我们介绍了如何测量和改进串行 Rust 程序的性能，同时展示了程序适合其用途。这是一个巨大的工作领域，有大量的文献可供参考。

• Rust 的 std::collections 绝对糟糕，可在www.reddit.com/r/rust/comments/52grcl/rusts_stdcollections_is_absolutely_horrible/找到。原文作者承认标题有点吸引点击，但 Reddit 上的讨论值得一读。标准库HashMap的原始作者对实现中的设计决策进行了评论。

• 罗宾汉哈希法，1985 年，Pedro Celis。这篇论文介绍了用于构建关联数组的罗宾汉哈希策略，是 Rust 中实现的基础。论文还探讨了没有进入 Rust 实现但可能对有志于构建哈希搜索结构的读者感兴趣的进一步搜索策略。

• 罗宾汉哈希法，Emmanuel Goossaert，可在codecapsule.com/2013/11/11/robin-hood-hashing/找到。Rust 标准库的 HashMap 持续引用这篇博客文章及其后续文章，文中均有链接。这里的描述比 Celis 的论文更高级，因此可能更容易理解。

• 通过算法复杂性攻击拒绝服务，2003 年，Scott Crosby 和 Dan Wallach。这篇论文概述了通过利用网络服务实现中的算法爆炸来进行的拒绝服务攻击。这篇论文的后果影响了 Rust 决定默认提供安全的 HashMap。

• QuickCheck：用于 Haskell 程序随机测试的轻量级工具，2000 年，Koen Claessen 和 John Hughes。这篇论文介绍了 QuickCheck 工具用于 Haskell，并将基于属性的测试引入了世界。这里的研究建立在之前的随机测试工作之上，但新颖之处在于意识到计算机已经足够快，可以支持类型指导的生成，并在单页附录中提供实现。许多后续论文都基于这一篇来提高属性测试器的探测能力。

• 随机测试评估，1984 年，Joe Duran 和 Simeon Ntafos。20 世纪 70 年代和 80 年代是软件测试的有趣时期。形式方法被视为即将到来，而首选的测试方法依赖于对程序结构的深入了解。Duran 和 Ntafos 将当时的理想技术与方法随机生成数据进行了比较，发现随机性与显著减少程序员的工作量相比更有优势。这篇论文将随机测试推向了舞台。

• 使用 QuickCheck 的经验：测试困难的东西并保持理智，2016 年，约翰·休斯。这篇论文是 Claessen 和休斯最初 QuickCheck 论文的后续，休斯在其中描述了他随后的十五年在做属性测试方面的经验。这篇论文中阐述的技术是对 2000 年论文中提出的技术的重要发展，对于任何将属性测试作为其工作一部分的人来说都值得研究。我的看法是，这应该是大多数人。

• 美国模糊跳鼠网站，可在lcamtuf.coredump.cx/afl找到。AFL 是针对高效变异输入以触发错误的研究成果。截至撰写本书时，它是同类产品中的佼佼者，并拥有长长的奖杯列表。网站提供了 AFL 的文档和相关研究，以深入了解其功能。

• 紧凑数据结构：实用方法，2016 年，贡萨洛·纳瓦罗。利用缓存局部性的主要技术之一是缩小工作集的各个元素，这意味着工作集中有更多的元素可用。紧凑数据结构，那些可以在其信息理论最小表示上进行操作的数据结构，是一个持续且令人兴奋的研究领域。纳瓦罗的书籍非常出色，对于任何对探索这一优化途径感兴趣的人来说都值得研究。

• vec_map，多位作者。vec_map是一个 Rust crate，它利用了本章HashMapU8相同的思想，但在一个通用实现中，与标准库 HashMap 完全兼容。源代码非常有趣，强烈推荐。

• 重新评估 Amdahl 定律，1988 年，约翰·古斯塔夫森。这是一篇非常简短的论文，清楚地解释了 Amdahl 的公式以及古斯塔夫森对其基本假设的反对。只有在阅读了几次之后，或者有人向你解释之后，才能清楚地看出这篇论文描述的是一个将串行部分缩小的解释。

• 跟踪特殊化问题（RFC 1210），可在github.com/rust-lang/rust/issues/31844找到。这个问题很好地揭示了 Rust 社区如何稳定一个主要功能的方式。原始的 RFC 来自 2016 年。从那时起，几乎每次接受之后，nightly 版本中都有一个功能标志用于实验，并且关于使工作稳定的影响的辩论一直在进行。

第三章：Rust 内存模型 - 所有权、引用和操作

在上一章，第二章，Rust 的顺序性能和测试，我们讨论了影响 Rust 程序顺序性能的因素。我们没有明确地讨论并发性能，因为缺乏关于 Rust 的抽象内存模型如何与机器的真实内存层次结构交互的足够信息。在本章中，我们将讨论 Rust 的内存模型，如何控制类型在内存中的布局，类型是如何被别名的，以及 Rust 的内存安全性是如何工作的。我们将深入研究标准库，以了解这些在实际中是如何体现的。本章还将检查生态系统中的一些常见 crate，这些 crate 将在本书后面的部分对我们感兴趣。请注意，当你阅读这一章时，rustc 的实现可能已经改变，这可能会使这里的代码列表与 rustc 本身的命名模式不再一致。如果你希望跟随，请查看 SHA da569fa9ddf8369a9809184d43c600dc06bd4b4d 的 Rust。

到本章结束时，我们将：

• 研究了 Rust 如何在内存中布局对象

• 讨论了 Rust 指向内存的各种方式及其保证

• 讨论了 Rust 如何分配和释放内存

• 讨论 Rust 如何表示栈和堆分配

• 研究了 Option、Cell、CellRef、Rc 和 Vec 的内部实现

技术要求

这需要有一个工作的 Rust 安装。验证安装的细节在第一章，预备知识 - 机器架构和 Rust 入门中有介绍。不需要额外的软件工具。

你可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。本章的源代码位于 Chapter03。

内存布局

Rust 有一系列机制来在内存中布局复合类型。它们如下：

• 数组

• 枚举

• 结构体

• 元组

这些在内存中的具体布局取决于选择的表现形式。默认情况下，Rust 中的所有内容都是 repr(Rust)。所有 repr(Rust) 类型都按照 2 的幂次对字节边界对齐。每个类型在内存中至少占用一个字节，然后是两个，然后是四个，以此类推。原始类型——u8、usize、bool 和 &T——都与其大小对齐。在 Rust 中，表示结构体的对齐方式取决于最大的字段。考虑以下结构体：

struct AGC {
  elapsed_time2: u16,
  elapsed_time1: u16,
  wait_list_upper: u32,
  wait_list_lower: u16,
  digital_autopilot: u16,
  fine_scale: u16
}

AGC 与 u32 对齐，并插入适当的填充以匹配 32 位对齐。Rust 将重新排序字段以实现最大打包。枚举不同，受到大量优化的影响，最值得注意的是空指针优化。请参见以下枚举：

enum AGCInstruction {
  TC,
  TCF,
  CCS(u8),
  B(u16),
  BZF,
}

这将按照以下方式布局：

struct AGCInstructionRepr {
  data: u16,
  tag: u8,
}

data字段足够宽，可以容纳最大的内部值，而tag允许区分不同的情况。当涉及到一个包含非空指针的枚举时，情况会变得复杂，其他情况不能引用相同的指针。Option<&T>表示如果在取消引用选项时发现空指针，Rust 可以假设发现了None情况。Rust 会优化掉Option<&T>的标签。

Rust 支持其他表示形式。repr(C)以 C 语言的方式在内存中布局类型，常用于 FFI 项目，我们将在本书后面的内容中看到。repr(packed)以repr(Rust)类似的方式布局类型，但不会添加填充，对齐仅发生在字节级别。这种表示形式可能会引起未对齐的加载，并对常见 CPU 的性能产生严重影响，特别是本书中我们关注的两种 CPU 架构。其余的表示形式与强制无字段枚举的大小有关——即没有数据在其变体中的枚举——这些表示形式对于确保与 ABI 兼容性有关的大小非常有用。

Rust 的分配默认发生在硬件栈上，这与其他底层语言的做法相同。堆分配必须由程序员显式执行，或者当创建一个包含某种内部存储的新类型时隐式执行。这里有一些复杂性。默认情况下，Rust 类型遵循移动语义：类型位在上下文之间适当地移动。例如：

fn project_flights() -> Vec<(u16, u8)> {
    let mut t = Vec::new();
    t.push((1968, 2));
    t.push((1969, 4));
    t.push((1970, 1));
    t.push((1971, 2));
    t.push((1972, 2));
    t
}

fn main() {
    let mut total: u8 = 0;
    let flights = project_flights();
    for &(_, flights) in flights.iter() {
        total += flights;
    }
    println!("{}", total);
}

project_flights函数在堆上分配一个新的Vec<(u16, u8)>，填充它，然后将堆分配的向量所有权返回给调用者。这并不意味着t的位从project_flights的栈帧中复制过来，而是指针t从project_flights的栈返回到main。在 Rust 中，可以通过使用Copy特质来实现复制语义。Copy类型将在内存中从一个地方复制到另一个地方。Rust 的原始类型是Copy——复制它们与移动它们一样快，特别是当类型小于本地指针时。除非你的类型实现了Drop特质（定义了类型如何释放自身），否则可以实现你自己的类型的Copy。这个限制在 Rust 代码（不使用unsafe）中消除了双重释放的可能性。以下代码块为两个用户定义的类型推导了Copy，是一个糟糕的随机生成器的示例：

#[derive(Clone, Copy, PartialEq, Eq)]
enum Project {
    Apollo,
    Gemini,
    Mercury,
}

#[derive(Clone, Copy)]
struct Mission {
    project: Project,
    number: u8,
    duration_days: u8,
}

fn flight() -> Mission {
    Mission {
        project: Project::Apollo,
        number: 8,
        duration_days: 6,
    }
}

fn main() {
    assert_eq!(::std::mem::size_of::<Mission>(), 3);
    let mission = flight();
    if mission.project == Project::Apollo && mission.number == 8 {
        assert_eq!(mission.duration_days, 6);
    }
}

内存指针

Rust 定义了几种指针类型，每种都有特定的用途。&T 是一个共享引用，可能会有许多该共享引用的副本。&T 的拥有者不一定拥有 T，并且可能无法修改它。共享引用是不可变的。可变引用——写成 &mut T——也不一定意味着其他 &mut T 必然拥有 T，但引用可以用来修改 T。对于任何 T，可能只有一个 &mut T 引用。这使某些代码变得复杂，但意味着 Rust 能够证明两个变量在内存中不重叠，从而解锁了 C/C++ 中不存在的各种优化机会。Rust 引用被设计成编译器能够证明所引用类型的活性：引用不能悬空。这不是 Rust 的原始指针类型——*const T 和 *mut T——的工作方式，它们与 C 指针类似：它们严格上是内存中的一个地址，对该地址的数据不提供任何保证。因此，许多原始指针的操作都需要 unsafe 关键字，并且它们几乎总是仅在性能敏感的代码或 FFI 接口上下文中出现。换句话说，原始指针可能为空；引用永远不会为空。

关于引用的规则通常会在意外地对可变引用进行不可变借用的情况下引起困难。Rust 文档使用以下小型程序来展示这种困难：

fn main() {
    let mut x: u8 = 5;
    let y: &mut u8 = &mut x;

    *y += 1;

    println!("{}", x);
}

println! 宏通过引用接收其参数，在这里隐式地创建了一个 &x。编译器拒绝了这个程序，因为 y: &mut u8 是无效的。如果这个程序能够编译，我们就会面临 y 的更新和 x 的读取之间的竞争条件，这取决于 CPU 和内存排序。当与结构一起工作时，引用的排他性可能会限制潜在的应用。Rust 允许程序分割结构的借用，只要不重叠的字段不能被别名。

我们在以下简短的程序中展示了这一点：

use std::fmt;

enum Project {
    Apollo,
    Gemini,
    Mercury,
}

impl fmt::Display for Project {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            Project::Apollo => write!(f, "Apollo"),
            Project::Mercury => write!(f, "Mercury"),
            Project::Gemini => write!(f, "Gemini"),
        }
    }
}

struct Mission {
    project: Project,
    number: u8,
    duration_days: u8,
}

fn main() {
    let mut mission = Mission {
        project: Project::Gemini,
        number: 2,
        duration_days: 0,
    };
    let proj: &Project = &mission.project;
    let num: &mut u8 = &mut mission.number;
    let dur: &mut u8 = &mut mission.duration_days;

    *num = 12;
    *dur = 3;

    println!("{} {} flew for {} days", proj, num, dur);
}

这种技巧对于通用容器类型来说很难甚至不可能实现。考虑一个映射，其中两个键映射到相同的引用 T。或者，现在考虑一个切片：

use std::fmt;

enum Project {
    Apollo,
    Gemini,
    Mercury,
}

impl fmt::Display for Project {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            Project::Apollo => write!(f, "Apollo"),
            Project::Mercury => write!(f, "Mercury"),
            Project::Gemini => write!(f, "Gemini"),
        }
    }
}

struct Mission {
    project: Project,
    number: u8,
    duration_days: u8,
}

fn main() {
    let mut missions: [Mission; 2] = [
        Mission {
            project: Project::Gemini,
            number: 2,
            duration_days: 0,
        },
        Mission {
            project: Project::Gemini,
            number: 12,
            duration_days: 2,
        },
    ];

    let gemini_2 = &mut missions[0];
    let _gemini_12 = &mut missions[1];

    println!(
        "{} {} flew for {} days",
        gemini_2.project, gemini_2.number, gemini_2.duration_days
    );
}

这个程序编译失败，错误如下：

> rustc borrow_split_array.rs
error[E0499]: cannot borrow `missions[..]` as mutable more than once at a time
  --> borrow_split_array.rs:40:27
   |
39 |     let gemini_2 = &mut missions[0];
   |                         ----------- first mutable borrow occurs here
40 |     let _gemini_12 = &mut missions[1];
   |                           ^^^^^^^^^^^ second mutable borrow occurs here
...
46 | }
   | - first borrow ends here

error: aborting due to previous error

我们，程序员，知道这是安全的——gemini_2 和 gemini_12 在内存中不重叠——但是编译器无法证明这一点。如果我们做了以下操作：

use std::fmt;

enum Project {
    Apollo,
    Gemini,
    Mercury,
}

impl fmt::Display for Project {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            Project::Apollo => write!(f, "Apollo"),
            Project::Mercury => write!(f, "Mercury"),
            Project::Gemini => write!(f, "Gemini"),
        }
    }
}

struct Mission {
    project: Project,
    number: u8,
    duration_days: u8,
}

fn main() {
    let gemini_2 = Mission {
        project: Project::Gemini,
        number: 2,
        duration_days: 0,
    };

    let mut missions: [&Mission; 2] = [&gemini_2, &gemini_2];

    let m0 = &mut missions[0];
    let _m1 = &mut missions[1];

    println!(
        "{} {} flew for {} days",
        m0.project, m0.number, m0.duration_days
    );
}

根据定义，missions[0] 和 missions[1] 在内存中重叠。我们，程序员，知道我们正在违反别名规则，而编译器出于保守考虑，假设规则正在被违反。

分配和释放内存

分配释放可以通过两种方式之一发生，这取决于类型是在栈上还是在堆上分配的。如果是在栈上，当栈帧本身不再存在时，类型就会被释放。每个 Rust 栈帧都是完全分配但未初始化地来到这个世界，并在其关联的函数退出时离开这个世界。堆分配的类型在最后一个有效的绑定移出作用域时被释放，无论是通过程序的正常流程还是通过程序员显式调用的std::mem::drop。drop的实现如下：

fn drop<T>(_x: T) { }

_x的值被移动到drop中——这意味着没有其他对_x的借用——然后当drop退出时立即超出作用域。然而，显式drop不能从作用域中删除项目，因此与结构体的微妙交互将发生，在这些结构体中，Rust 编译器无法证明非重叠别名等情况。drop文档讨论了几个案例，值得回顾这些材料。

任何可以被释放的 Rust 类型——这意味着它不是Copy——都将实现Drop特质，这是一个只有一个函数drop(&mut self)的特质。Drop::drop不能被显式调用，当类型超出作用域或可以被std::mem::drop调用时，它就会被调用，正如之前讨论的那样。

到目前为止，在本章中，我们讨论了内存中类型的布局和在堆上的分配，但没有完全讨论 Rust 内存模型中分配本身是如何工作的。强制堆分配的最简单方法就是使用std::boxed::Box。实际上，Rust 对Box的文档——也简称为 box——将其描述为 Rust 中最简单的堆分配形式。也就是说，Box<T>在堆上为类型T分配足够的空间，并作为该分配的所有者。当 box 被丢弃时，T的丢弃就会发生。以下是Box<T>的定义，直接来自标准库，在文件src/liballoc/boxed.rs中：

pub struct Box<T: ?Sized>(Unique<T>);

类型的大小

这里有两个重要的事情我们在这本书中还没有遇到——Sized和Unique。首先，Sized，或者更准确地说，std::marker::Sized。Sized是 Rust 的一个trait，它将类型约束为在编译时具有已知的大小。在 Rust 中几乎所有的东西都有一个隐式的Sized约束，我们可以检查它。例如：

use std::mem;

#[allow(dead_code)]
enum Project {
    Mercury { mission: u8 },
    Gemini { mission: u8 },
    Apollo { mission: u8 },
    Shuttle { mission: u8 },
}

fn main() {
    assert_eq!(1, mem::size_of::<u8>());
    assert_eq!(2, mem::size_of::<Project>());

    let ptr_sz = mem::size_of::<usize>();
    assert_eq!(ptr_sz, mem::size_of::<&Project>());

    let vec_sz = mem::size_of::<usize>() * 2 + ptr_sz;
    assert_eq!(vec_sz, mem::size_of::<Vec<Project>>());
}

u8 是一个字节，Project 是用于区分枚举变体的字节以及内部任务字节，指针是机器字的大小——一个 usize，而 Vec<T> 保证是一个指针和两个 usize 字段，无论 T 的大小如何。Vec<T> 和 T 之间有一些有趣的事情发生，我们将在本章后面深入探讨。请注意，我们几乎在 Rust 中说到了所有东西都有一个隐式的 Sized 约束。Rust 支持 动态大小类型，这些类型没有已知的大小或对齐。Rust 需要已知的大小和对齐，因此所有 DSTs 都必须位于引用或指针之后。切片——对连续内存的视图——就是这样一种类型。在以下程序中，编译器将无法确定值的切片的大小：

use std::time::{SystemTime, UNIX_EPOCH};

fn main() {
    let values = vec![0, 1, 2, 3, 4, 5, 7, 8, 9, 10];
    let cur: usize = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .unwrap()
        .as_secs() as usize;
    let cap: usize = cur % values.len();

    let slc: &[u8] = &values[0..cap];

    println!("{:?}", slc);
}

切片是内存块的一种视图，该内存块以指针和长度表示，正如原始类型切片的文档所述。技巧在于长度是在运行时确定的。以下程序将能够编译：

fn main() {
    let values = vec![0, 1, 2, 3, 4, 5, 7, 8, 9, 10];
    let slc: &[u8] = &values[0..10_000];

    println!("{:?}", slc);
}

然而，之前的代码在运行时会引发恐慌：

> ./past_the_end thread 
'main' panicked at 'index 10000 out of range for slice of length 10', libcore/slice/mod.rs:785:5 note: Run with `RUST_BACKTRACE=1` for a backtrace.

Rust 允许程序员将 DSTs（可变大小类型）作为 struct 的最后一个字段，如下所示：

struct ImportantThing {
  tag: u8,
  data: [u8],
}

然而，这会导致结构体本身成为 DST。

静态和动态分发

在 Rust 中，特质对象同样没有静态已知的大小。特质对象是 Rust 执行动态分发的方式。优先考虑 Rust 是一种静态分发语言，因为存在更多的内联和优化机会——编译器知道得更多。考虑以下代码：

use std::ops::Add;

fn sd_add<T: Add<Output=T>>(x: T, y: T) -> T {
    x + y
}

fn main() {
    assert_eq!(48, sd_add(16 as u8, 32 as u8));
    assert_eq!(48, sd_add(16 as u64, 32 as u64));
}

这里，我们定义了一个函数，sd_add<T: Add<Output=T>>(x: T, y: T) -> T。Rust，就像 C++ 一样，将在编译时进行单态化，生成两个 sd_add 函数，一个用于 u8，另一个用于 u64。像 C++ 一样，这可能会增加 Rust 程序的代码大小并减慢编译速度，但好处是在调用者位置允许内联，由于类型特化，可能更有效的实现，以及更少的分支。

当静态分发不可取时，程序员可以构建特质对象以执行动态分发。特质对象没有已知的大小——实际上，它们可以是实现该特质的任何 T 类型——因此，就像切片一样，必须位于某种指针之后。在这本书中，动态分发不会得到太多应用。强烈建议读者查阅 std::raw::TraitObject 的文档，以获取 Rust 特质对象概念的详细信息。

零大小类型

Rust 还支持零大小类型或 ZST；没有字段的 struct、单位类型()或没有大小的数组都是零大小的。类型没有大小的事实对优化和死树移除是一个福音。Rust API 通常包括如下返回类型：Result<(), a_mod::ErrorKind>。这种类型表示，虽然函数可能会出错，但在正常路径下的返回值是单位类型。这些类型在实践中相对较少，但它们是不安全的，Rust 必须意识到它们。许多分配器在请求分配零字节时返回空指针——使得 ZST 的分配与分配器无法找到空闲内存的情况无法区分——并且从 ZST 的指针偏移量为零。这两个考虑因素在本章中都将非常重要。

带框的类型

那是Sized特性，但?Sized是什么意思呢？?标志表示相关的特性是可选的。因此，一个框是 Rust 中参数化其他类型T的类型，T可能具有大小也可能不具有大小。一个框是一种指向堆分配存储的指针。让我们进一步看看它的实现。Unique<T>又是怎么回事呢？这个类型是向 Rust 编译器发出信号，表示某些*mut T是非空的，并且唯一所有者是T，即使T是在Unique外部分配的。Unique的定义如下：

pub struct Unique<T: ?Sized> {
    pointer: NonZero<*const T>,
    // NOTE: this marker has no consequences for variance, but is
    // necessary for dropck to understand that we logically 
    // own a `T`.
    _marker: PhantomData<T>,
}

NonZero<T>是一个rustc源代码描述为原始指针和整数的包装类型，这些指针和整数永远不会是NULL或0，这可能会允许某些优化。它以特殊方式注释，以允许本章其他地方讨论的空指针优化。Unique也因其使用PhantomData<T>而引起兴趣。实际上，PhantomData是一个零大小类型，定义为pub struct PhantomData<T:?Sized>;。此类型指示 Rust 编译器将PhantomData<T>视为拥有T，尽管最终PhantomData无处存储其新发现的T。这对于必须通过维护指向T的非零常量指针来拥有<T>的Unique<T>来说效果很好，但它本身并不在除堆以外的任何地方存储T。因此，一个框是一个唯一的、非空的指针，指向内存中某个地方分配的东西，但不在框的存储空间内。

框的内部是编译器内建函数：它们位于分配器和借用检查器之间的交互中，在 Rust 的借用检查器中是一个特殊考虑。考虑到这一点，我们将避免深入挖掘Box的内部细节，因为它们会随着编译器版本的更新而变化，而这本书明确不是一本关于rustc内部机制的书籍。然而，就我们的目的而言，考虑由框暴露的 API 是有价值的。关键函数包括：

• fn from_raw(raw: *mut T) -> Box<T>

• fn from_unique(u: Unique<T>) -> Box<T>

• fn into_raw(b: Box<T>) -> *mut T

• fn into_unique(b: Box<T>) -> Unique<T>

• fn leak<'a>(b: Box<T>) -> &'a mut T

from_raw 和 from_unique 都是 unsafe 的。如果原始指针被 boxed 多次，或者如果从一个与另一个重叠的指针创建了一个 box，那么从原始指针的转换是不安全的，例如。还有其他可能性。从 Unique<T> 的转换是不安全的，因为 T 可能或可能不被 Unique 所拥有，从而导致 box 不是其内存的唯一所有者。然而，into_* 函数是安全的，因为生成的指针将是有效的，但调用者不会对管理内存的生命周期承担全部责任。Box 文档指出，调用者可以自己释放内存或将指针转换回它们原来的类型，并允许 Rust 为他们处理。本书将采用后一种方法。最后，还有 leak。leak 是一个有趣的概念，但在稳定渠道上不可用，但对于将软件部署到嵌入式目标的应用程序来说值得讨论。嵌入式系统的一种常见内存管理策略是在程序的生命周期内预分配所有必要的内存，并且只在该内存上操作。在 Rust 中，如果你想要一个固定大小的未初始化内存：数组和其他原始类型，这是微不足道的。如果你在程序开始时需要堆分配，情况就更加复杂了。这就是 leak 的作用：它使内存从 box（堆分配）泄漏到任何你想要的地方。当泄漏的内存打算在程序的生命周期内存在——进入 static 生命周期——就没有问题。以下是一个例子，直接来自 leak 的文档：

#![feature(box_leak)]

fn main() {
    let x = Box::new(41);
    let static_ref: &'static mut usize = Box::leak(x);
    *static_ref += 1;
    assert_eq!(*static_ref, 42);
}

在这里，我们看到在堆上分配了一个新的 usize，泄漏到 static_ref——一个具有静态生命周期的可变引用——然后在整个程序的生命周期内对其进行操作。

自定义分配器

可以将自定义分配器插入 Rust，就像在 C++ 或类似的系统级编程语言中做的那样。默认情况下，在大多数目标上，Rust 使用 jemalloc，并有一个系统提供的分配器的后备替代方案。在嵌入式应用程序中，可能没有系统，更不用说分配器了，因此建议感兴趣的读者查阅 RFC 1183 (github.com/rust-lang/rfcs/blob/master/text/1183-swap-out-jemalloc.md)、RFC 1398 (github.com/rust-lang/rfcs/pull/1398) 以及相关的 RFC。截至撰写本文时，将自定义分配器插入稳定 Rust 的接口正在积极讨论中，并且此类功能仅在 nightly Rust 中可用。本书将不会使用自定义分配器。

实现

在第二章，“顺序 Rust 性能和测试”中，我们非常简要地探讨了std::collections::HashMap的实现。让我们继续以这种方式剖析标准库，特别关注出现的内存问题。

Option

让我们检查Option<T>。我们已经在本章中讨论了Option<T>；它由于特别空的None变体而受到空指针优化的影响。Option就像你可能想象的那样简单，它在src/libcore/option.rs中定义：

#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
#[stable(feature = "rust1", since = "1.0.0")]
pub enum Option<T> {
    /// No value
    #[stable(feature = "rust1", since = "1.0.0")]
    None,
    /// Some value `T`
    #[stable(feature = "rust1", since = "1.0.0")]
    Some(#[stable(feature = "rust1", since = "1.0.0")] T),
}

正如 Rust 内部经常发生的那样，有许多标志用于控制新功能何时何地出现在哪个通道中，以及如何生成文档。Option<T>的一个稍微整洁的表达式是：

#[derive(Clone, Copy, PartialEq, PartialOrd, Eq, Ord, Debug, Hash)]
pub enum Option<T> {
    None,
    Some(T),
}

这非常简单，就像你第一次想到它时可能实现选项类型一样。Option是其内部T的所有者，并且能够根据通常的限制传递对该内部数据的引用。例如：

    pub fn as_mut(&mut self) -> Option<&mut T> {
        match *self {
            Some(ref mut x) => Some(x),
            None => None,
        }
    }

Rust 在每个trait: Self内部暴露一个特殊的特质类型。它简单地解糖为引用特质类型，在这种情况下，Option<T>。&mut self是self: &mut Self的缩写，同样&self是self: &Self的缩写。as_mut随后分配一个新的选项，其内部类型是原始内部类型的可变引用。现在，考虑一下谦逊的map：

    pub fn map<U, F: FnOnce(T) -> U>(self, f: F) -> Option<U> {
        match self {
            Some(x) => Some(f(x)),
            None => None,
        }
    }

Rust 允许将闭包作为函数的参数。通过这种方式，Rust 与高级语言，尤其是函数式编程语言相似。与这些高级编程语言不同，Rust 对闭包的捕获方式、调用总数和可变性有约束。在这里，我们看到FnOnce特质被用来限制传递给 map 函数的闭包f为单次使用。函数特质，所有都在std::ops中定义，如下所示：

• Fn

• FnMut

• FnOnce

第一个特质Fn，Rust 文档描述为是一个接受不可变接收者的调用操作符。这可能有点难以理解，直到我们查看src/libcore/ops/function.rs中Fn的定义：

pub trait Fn<Args>: FnMut<Args> {
    /// Performs the call operation.
    #[unstable(feature = "fn_traits", issue = "29625")]
    extern "rust-call" fn call(&self, args: Args) -> Self::Output;
}

现在它更难以理解了！但是，我们可以回溯。Args与std::env::Args不同，但扮演着类似的角色，即作为函数参数的占位符，只是在类型级别上。: FnMut<Args>意味着FnMut<Args>是Fn<Args>的超特质：所有FnMut的方法在用作特质对象时都可用。回想一下，特质对象在之前讨论的动态调度中找到了用途。这也意味着在静态调度的情况下，任何Fn的实例都可以用在期望FnMut的地方。对理解Fn特别感兴趣的是：

extern "rust-call" fn call(&self, args: Args) -> Self::Output;

我们将分部分来处理这个问题。首先，extern "rust-call"。在这里，我们定义了一个使用 "rust-call" ABI 的内联 extern 块。Rust 支持许多 ABIs，其中三个是跨平台的，并且无论平台如何都保证支持：

• extern "Rust" fn，对于所有未指定其他情况的 Rust 函数是隐式的

• extern "C" fn，常用于 FFI，简写为 extern fn

• extern "system" fn，相当于 extern "C" fn，但针对一些特殊平台

"rust-call" 不出现在该列表中，因为它是一个 Rust 特定的 ABI，它还包括：

• extern "rust-intrinsic" fn，特定于 rustc 内置函数

• extern "rust-call" fn，所有 Fn::call 函数的 ABI

• extern "platform-intrinsic" fn，文档指出程序员永远不需要处理的东西

在这里，我们向 Rust 编译器发出信号，表示该函数应以特殊的调用 ABI 处理。当启用不稳定的 fnbox 功能标志时，这个特定的 extern 在编写实现 Fn 特性的 traits 时非常重要，因为 box 也会这样做：

impl<'a, A, R> FnOnce<A> for Box<FnBox<A, Output = R> + 'a> {
    type Output = R;

    extern "rust-call" fn call_once(self, args: A) -> R {
        self.call_box(args)
    }
}

其次，fn call(&self, args: Args)。实现类型以不可变引用的形式传入，除了传入的参数；这是文档中提到的不可变接收者。这里的最后一部分是 -> Self::Output，这是在调用操作符使用后的返回类型。这个关联类型默认为 Self，但可以被实现者设置。

FnMut 与 Fn 类似，只是它接受 &mut self 而不是 &self，而 FnOnce 是其超特化：

pub trait FnMut<Args>: FnOnce<Args> {
    /// Performs the call operation.
    #[unstable(feature = "fn_traits", issue = "29625")]
    extern "rust-call" fn call_mut(&mut self, args: Args) 
        -> Self::Output;
}

只有 FnOnce 在其定义中有所不同：

pub trait FnOnce<Args> {
    /// The returned type after the call operator is used.
    #[stable(feature = "fn_once_output", since = "1.12.0")]
    type Output;

    /// Performs the call operation.
    #[unstable(feature = "fn_traits", issue = "29625")]
    extern "rust-call" fn call_once(self, args: Args) -> Self::Output;
}

在这里，我们看到 Self::Output 作为关联类型出现，并注意 FnOnce 的实现是以 call_once 而不是 call 为基础的。现在我们知道 FnOnce 是 FnMut 的超特化，而 FnMut 是 Fn 的超特化，而且这个属性是传递的：如果对 Fn 调用 FnOnce，则可以使用它。函数特质的许多确切实现都保留在编译器内部，这些实现的细节会随着内部的变化而跳转。实际上，"rust-call"、extern 的意思是指 Fn traits 不能在特殊、编译器特定的上下文中实现；需要启用在夜间构建中确切的功能标志、它们的用途和即将到来的更改并未记录。幸运的是，闭包和函数指针隐式地实现了函数特质。例如：

fn mlen(input: &str) -> usize {
    input.len()
}

fn main() {
    let v: Option<&str> = Some("hope");

    assert_eq!(v.map(|s| s.len()), v.map(mlen));
}

编译器足够智能，可以为我们找出细节。

从概念上讲，Result<T> 是一个类似于 Option<T> 的类型，但它能够在其 Err 变体中传达额外的信息。实际上，src/libcore/result.rs 中的实现与我们最初可能写的方式非常相似，尽管与 Option 类似：

pub enum Result<T, E> {
    /// Contains the success value
    #[stable(feature = "rust1", since = "1.0.0")]
    Ok(#[stable(feature = "rust1", since = "1.0.0")] T),

    /// Contains the error value
    #[stable(feature = "rust1", since = "1.0.0")]
    Err(#[stable(feature = "rust1", since = "1.0.0")] E),
}

Cell 和 RefCell

到目前为止，在本章中，我们讨论的可变引用具有 Rust 所称的继承可变性的属性。也就是说，当我们继承其所有权或对值进行独占修改的权利——通过 &mut——时，值变得可变。在 Rust 中，继承可变性是首选的，因为它在编译时是静态可强制执行的——我们程序中关于内存变异的任何缺陷都会在编译时被发现。Rust 提供了内部可变性的设施，即对不可变类型的一部分可用的可变性。文档将内部可变性称为一种最后的手段，但尽管不常见，在实践中也并不罕见。Rust 中内部可变性的两种选择是 Cell<T> 和 RefCell<T>。

让我们考虑 Cell<T>。它是如何使用的？正如建议的那样，Cell<T> 在某些字段或字段需要可变而您关心的 T 是 T: Copy 时非常有用。考虑一个执行搜索操作的图结构。这在逻辑上是不可变的——在搜索过程中不需要修改图结构。但是，也考虑一下我们想要记录沿着图边沿的总遍历次数的情况。我们的选择是违反图搜索的逻辑不可变性、要求在图之外存储，或者将一个内部可变的计数器插入到图中。哪种选择最好将取决于具体情况。以下是一个 Cell<T> 的例子，与图搜索相比，这个例子要简单得多：

use std::cell::Cell;

enum Project {
    Apollo,
    Gemini,
    Mercury,
}

struct Mission {
    project: Project,
    number: u8,
    duration_days: Cell<u8>,
}

fn main() {
    let mission = Mission {
        project: Project::Mercury,
        number: 7,
        duration_days: Cell::new(255),
    };

    mission.duration_days.set(0);
    assert_eq!(0, mission.duration_days.get());
}

当然，这有点人为。内部可变性通常在非平凡的情况下出现。请注意，Cell<u8> 必须通过 get 和 set 方法来操作，这与直接设置和读取或通过指针读取的正常过程相反。让我们深入探讨 Cell<T> 的实现，它在 src/libcore/cell.rs 中定义：

pub struct Cell<T> {
    value: UnsafeCell<T>,
}

如同在 Rust 内部常见的那样，一个安全的接口隐藏了一个不安全的内部核心，正如我们在第二章，“顺序 Rust 性能和测试”中看到的那样，使用 HashMap。那么 UnsafeCell 的定义是什么？

pub struct UnsafeCell<T: ?Sized> {
    value: T,
}

特别值得注意的是紧随其后的一个实现：

impl<T: ?Sized> !Sync for UnsafeCell<T> {}

我们将在下一章更详细地讨论 Sync。现在只需说，任何线程安全的类型都必须实现 Sync——许多类型会自动实现——通过禁用 Sync 特性为 UnsafeCell<T>——即 !Sync 的含义——类型被特别标记为非线程安全。也就是说，任何线程都可以在任何时候操作 UnsafeCell 所拥有的数据。正如我们之前讨论的，Rust 能够利用 &T 保证不会在任何地方是可变的以及 &mut T 是唯一的这一知识进行大量的优化。UnsafeCell<T> 是 Rust 提供的 唯一 一种关闭这些编译器优化方法；虽然可以进入一个不安全块并将 &T 转换为 &mut T，但这被明确指出是未定义的行为。UnsafeCell<T> 的关键是，客户端可以检索到多个对内部数据的可变引用，即使 UnsafeCell<T> 本身是可变的。确保在任何时候只有一个可变引用的责任在于调用者。UnsafeCell 的实现——为了清晰起见，去掉了注释——是简短的：

impl<T> UnsafeCell<T> {
    pub const fn new(value: T) -> UnsafeCell<T> {
        UnsafeCell { value: value }
    }

    pub unsafe fn into_inner(self) -> T {
        self.value
    }
}

impl<T: ?Sized> UnsafeCell<T> {
    pub fn get(&self) -> *mut T {
        &self.value as *const T as *mut T
    }
}

这又带我们回到了 Cell<T>。我们知道 Cell<T> 是建立在不安全抽象之上的，我们必须要小心不要违反 &mut T 的唯一性约束。这是如何做到的？首先，Cell<T> 的构建是直接的，正如你所期望的：

impl<T> Cell<T> {
    pub const fn new(value: T) -> Cell<T> {
        Cell {
            value: UnsafeCell::new(value),
        }
    }

const fn 可能会让人感到意外，因为截至撰写本书时，它是一个仅在夜间构建版本中存在的特性。在 Rust 中，常量函数是在编译时进行评估的。这种特定定义对程序员的益处在于，Cell::new 的结果可以被分配给一个常量变量，这个变量将存在于程序的整个生命周期中。as_ptr 和 get_mut 是对底层 T 的不同视图，一个是原始可变指针，另一个是可变引用：

    pub fn as_ptr(&self) -> *mut T {
        self.value.get()
    }

    pub fn get_mut(&mut self) -> &mut T {
        unsafe {
            &mut *self.value.get()
        }
    }

    pub fn into_inner(self) -> T {
        unsafe { self.value.into_inner() }
    }

注意，虽然 get_mut 的内部是不安全的，但借用检查器被用来处理保持 &mut T 唯一性的问题，因此 Cell::get_mut 本身可以是安全的。Cell::as_ptr 没有标记为不安全——在 Rust 中接收原始指针是安全的——但任何调用者都必须在一个不安全块中对那个原始指针进行解引用：可能存在多个原始的可变指针在浮动。将新值设置到单元格中是通过替换来完成的，这将在后面讨论，但需要仔细注意强制丢弃从单元格中拉出的 T：

    pub fn set(&self, val: T) {
        let old = self.replace(val);
        drop(old);
    }

Cell::swap 和 Cell::replace 是基于 std::ptr 和 std::mem 的底层内存操作工具完成的。swap 的目的是用一个单元格的内部替换另一个单元格的内部。其定义如下：

    pub fn swap(&self, other: &Self) {
        if ptr::eq(self, other) {
            return;
        }
        unsafe {
            ptr::swap(self.value.get(), other.value.get());
        }
    }

swap 是通过 std::ptr::swap 来实现的，这是一个被文档化的函数，它通过传递给它的原始指针作为参数来复制内存。你会注意到 Cell::swap 小心避免当传递的 other 等同于 self 时的 swap。当我们查看 std::ptr::swap 的定义时，这个原因就变得清晰了，该定义位于 src/libcore/ptr.rs：

pub unsafe fn swap<T>(x: *mut T, y: *mut T) {
    // Give ourselves some scratch space to work with
    let mut tmp: T = mem::uninitialized();

    // Perform the swap
    copy_nonoverlapping(x, &mut tmp, 1);
    copy(y, x, 1); // `x` and `y` may overlap
    copy_nonoverlapping(&tmp, y, 1);

    // y and t now point to the same thing, but we need to completely 
    forget `tmp`
    // because it's no longer relevant.
    mem::forget(tmp);
}

在这里，copy_nonoverlapping 和复制的确切细节并不重要，除了注意交换确实需要分配未初始化的空间，并从这个空间中来回复制。如果你不需要这样做，避免这项工作是很明智的。Cell::replace 的工作方式类似：

    pub fn replace(&self, val: T) -> T {
        mem::replace(unsafe { &mut *self.value.get() }, val)
    }
}

std::mem::replace 接受一个 &mut T 和一个 T，然后将 &mut T 中的值替换为传入的 val，返回旧值，并且不丢弃。std::mem::replace 的定义在 src/libcore/mem.rs 中，如下所示：

pub fn replace<T>(dest: &mut T, mut src: T) -> T {
    swap(dest, &mut src);
    src
}

追踪同一模块中 swap 的定义，我们发现它是这样的：

pub fn swap<T>(x: &mut T, y: &mut T) {
    unsafe {
        ptr::swap_nonoverlapping(x, y, 1);
    }
}

std::ptr::swap_nonoverlapping 的定义如下：

pub unsafe fn swap_nonoverlapping<T>(x: *mut T, y: *mut T, count: usize) {
    let x = x as *mut u8;
    let y = y as *mut u8;
    let len = mem::size_of::<T>() * count;
    swap_nonoverlapping_bytes(x, y, len)
}

最后，私有的 std::ptr::swap_nonoverlapping_bytes 定义如下：

unsafe fn swap_nonoverlapping_bytes(x: *mut u8, y: *mut u8, len: usize) {
    // The approach here is to utilize simd to swap x & y efficiently. 
    // Testing reveals that swapping either 32 bytes or 64 bytes at
    // a time is most efficient for intel Haswell E processors. 
    // LLVM is more able to optimize if we give a struct a 
    // #[repr(simd)], even if we don't actually use this struct
    // directly.
    //
    // FIXME repr(simd) broken on emscripten and redox
    // It's also broken on big-endian powerpc64 and s390x.  #42778
    #[cfg_attr(not(any(target_os = "emscripten", target_os = "redox",
                       target_endian = "big")),
               repr(simd))]
    struct Block(u64, u64, u64, u64);
    struct UnalignedBlock(u64, u64, u64, u64);

    let block_size = mem::size_of::<Block>();

    // Loop through x & y, copying them `Block` at a time
    // The optimizer should unroll the loop fully for most types
    // N.B. We can't use a for loop as the `range` impl calls 
    // `mem::swap` recursively
    let mut i = 0;
    while i + block_size <= len {
        // Create some uninitialized memory as scratch space

        // Declaring `t` here avoids aligning the stack when this loop 
        // is unused
        let mut t: Block = mem::uninitialized();
        let t = &mut t as *mut _ as *mut u8;
        let x = x.offset(i as isize);
        let y = y.offset(i as isize);

        // Swap a block of bytes of x & y, using t as a temporary 
        // buffer. This should be optimized into efficient SIMD 
        // operations where available
        copy_nonoverlapping(x, t, block_size);
        copy_nonoverlapping(y, x, block_size);
        copy_nonoverlapping(t, y, block_size);
        i += block_size;
    }

    if i < len {
        // Swap any remaining bytes
        let mut t: UnalignedBlock = mem::uninitialized();
        let rem = len - i;

        let t = &mut t as *mut _ as *mut u8;
        let x = x.offset(i as isize);
        let y = y.offset(i as isize);

        copy_nonoverlapping(x, t, rem);
        copy_nonoverlapping(y, x, rem);
        copy_nonoverlapping(t, y, rem);
    }
}

哇！这真是一个兔子洞。最终，我们在这里发现的是 std::mem::replace 是通过在内存中一个非重叠位置到另一个位置的块复制来定义的，这个过程是通过利用 LLVM 在通用处理器上优化位操作的能力，Rust 开发者试图使其尽可能高效。真不错。

那么 RefCell<T> 呢？它也是一个在 UnsafeCell<T> 之上的安全抽象，除了 Cell<T> 的复制限制被取消。这使得实现稍微复杂一些，正如我们将看到的：

pub struct RefCell<T: ?Sized> {
    borrow: Cell<BorrowFlag>,
    value: UnsafeCell<T>,
}

与 Cell 一样，RefCell 也有一个内部不安全值，这一点是相同的。有趣的是 borrow: Cell<BorrowFlag>。RefCell<T> 是 Cell<T> 的客户端，这很有道理，因为不可变的 RefCell 将需要内部可变性来跟踪其内部数据的借用总数。BorrowFlag 的定义如下：

// Values [1, MAX-1] represent the number of `Ref` active
// (will not outgrow its range since `usize` is the size 
// of the address space)
type BorrowFlag = usize;
const UNUSED: BorrowFlag = 0;
const WRITING: BorrowFlag = !0;

RefCell<T> 的实现类似于 Cell<T>。RefCell::replace 也是通过 std::mem::replace 来实现的，RefCell::swap 是通过 std::mem::swap 来实现的。有趣的地方在于 RefCell 中新出现的函数，这些是与借用相关的函数。我们将首先查看 try_borrow 和 try_borrow_mut，因为它们被用于其他借用函数的实现。try_borrow 的定义如下：

    pub fn try_borrow(&self) -> Result<Ref<T>, BorrowError> {
        match BorrowRef::new(&self.borrow) {
            Some(b) => Ok(Ref {
                value: unsafe { &*self.value.get() },
                borrow: b,
            }),
            None => Err(BorrowError { _private: () }),
        }
    }

BorrowRef 的定义如下：

struct BorrowRef<'b> {
    borrow: &'b Cell<BorrowFlag>,
}

impl<'b> BorrowRef<'b> {
    #[inline]
    fn new(borrow: &'b Cell<BorrowFlag>) -> Option<BorrowRef<'b>> {
        match borrow.get() {
            WRITING => None,
            b => {
                borrow.set(b + 1);
                Some(BorrowRef { borrow: borrow })
            },
        }
    }
}

impl<'b> Drop for BorrowRef<'b> {
    #[inline]
    fn drop(&mut self) {
        let borrow = self.borrow.get();
        debug_assert!(borrow != WRITING && borrow != UNUSED);
        self.borrow.set(borrow - 1);
    }
}

BorrowRef 是一个结构，它持有 RefCell<T> 的借用字段的引用。创建一个新的 BorrowRef 依赖于那个借用的值；如果值是 WRITING，则不会创建 BorrowRef——返回 None——否则，总的借用次数会增加。这实现了在需要写入时的互斥性，同时允许有多个读取者——当有写入引用时，try_borrow 不可能分配一个引用。现在，让我们考虑 try_borrow_mut：

    pub fn try_borrow_mut(&self) -> Result<RefMut<T>, BorrowMutError> {
        match BorrowRefMut::new(&self.borrow) {
            Some(b) => Ok(RefMut {
                value: unsafe { &mut *self.value.get() },
                borrow: b,
            }),
            None => Err(BorrowMutError { _private: () }),
        }
    }

再次，我们发现了一个基于另一种类型 BorrowRefMut 的实现：

struct BorrowRefMut<'b> {
    borrow: &'b Cell<BorrowFlag>,
}

impl<'b> Drop for BorrowRefMut<'b> {
    #[inline]
    fn drop(&mut self) {
        let borrow = self.borrow.get();
        debug_assert!(borrow == WRITING);
        self.borrow.set(UNUSED);
    }
}

impl<'b> BorrowRefMut<'b> {
    #[inline]
    fn new(borrow: &'b Cell<BorrowFlag>) -> Option<BorrowRefMut<'b>> {
        match borrow.get() {
            UNUSED => {
                borrow.set(WRITING);
                Some(BorrowRefMut { borrow: borrow })
            },
            _ => None,
        }
    }
}

关键点，就像 BorrowRef 一样，在于 BorrowRefMut::new。在这里，我们可以看到如果 RefCell 的内部借用未被使用，则借用被设置为写入，排除任何潜在的读取引用。同样，如果存在读取引用，创建可变引用将失败。因此，在运行时通过抽象一个允许打破该保证的不安全结构，我们持有排他性可变引用和多个不可变引用。

Rc

现在，在我们进入多项目容器之前，让我们考虑一个最后的单项目容器。我们将探讨由 Rust 文档描述的 Rc<T>，它是一个单线程引用计数的指针。引用计数指针与 Rust 的常规引用不同，因为它们虽然作为 Box<T> 在堆上分配，但克隆引用计数指针不会导致新的堆分配，而是进行位拷贝。相反，Rc<T> 内部的计数器会增加，这在某种程度上类似于 RefCell<T> 的工作方式。Rc<T> 的释放会减少内部计数器，当计数器的值等于零时，堆分配就会被释放。让我们看一下 src/liballoc/rc.s 的内部结构：

pub struct Rc<T: ?Sized> {
    ptr: Shared<RcBox<T>>,
    phantom: PhantomData<T>,
}

我们在本章中已经遇到了 PhantomData<T>，所以我们知道 Rc<T> 不会直接持有 T 的分配，但编译器会表现得好像它持有一样。我们还知道 T 可能是有大小的，也可能不是。我们需要了解的片段是 RcBox<T> 和 Shared<T>。让我们首先检查 Shared<T>。它的全名是 std::ptr::Shared<T>，它与 *mut X 类似的指针，除了它是非零的。创建新的 Shared<T> 有两种变体，const unsafe fn new_unchecked(ptr: *mut X) -> Self 和 fn new(ptr: *mut X) -> Option<Self>。在第一种变体中，调用者负责确保指针是非空的，而在第二种变体中，会检查指针是否为空，如下所示：

    pub fn new(ptr: *mut T) -> Option<Self> {
        NonZero::new(ptr as *const T).map(|nz| Shared { pointer: nz })
    }

我们在 src/libcore/nonzero.rs 中找到了 NonZero<T> 的定义和实现，如下所示：

pub struct NonZero<T: Zeroable>(T);

impl<T: Zeroable> NonZero<T> {
    /// Creates an instance of NonZero with the provided value.
    /// You must indeed ensure that the value is actually "non-zero".
    #[unstable(feature = "nonzero",
               reason = "needs an RFC to flesh out the design",
               issue = "27730")]
    #[inline]
    pub const unsafe fn new_unchecked(inner: T) -> Self {
        NonZero(inner)
    }

    /// Creates an instance of NonZero with the provided value.
    #[inline]
    pub fn new(inner: T) -> Option<Self> {
        if inner.is_zero() {
            None
        } else {
            Some(NonZero(inner))
        }
    }

    /// Gets the inner value.
    pub fn get(self) -> T {
        self.0
    }
}

Zeroable 是一个不稳定特质，它相当直接：

pub unsafe trait Zeroable {
    fn is_zero(&self) -> bool;
}

每个指针类型都实现了一个is_null() -> bool函数，这个特性将调用该函数，而NonZero::new则委托给Zeroable::is_zero。因此，存在Shared<T>时，给程序员提供的自由度与*mut T相同，但增加了关于指针可空情况的额外保证。回到Rc::new：

pub fn new(value: T) -> Rc<T> {
    Rc {
        // there is an implicit weak pointer owned by all the strong
        // pointers, which ensures that the weak destructor never frees
        // the allocation while the strong destructor is running, even
        // if the weak pointer is stored inside the strong one.
        ptr: Shared::from(Box::into_unique(box RcBox {
            strong: Cell::new(1),
            weak: Cell::new(1),
            value,
        })),
        phantom: PhantomData,
    }
}

Box::into_unique将Box<T>转换为Unique<T>——在本章中已讨论过——然后将其转换为Shared<T>。这个链保留了所需的非空保证并确保了唯一性。现在，关于RcBox中的强引用和弱引用又是怎样的呢？Rc<T>提供了一个方法，Self::downgrade(&self) -> Weak<T>，它产生一个非拥有指针，一个不保证引用数据存活性的指针，并且不扩展其生命周期。这被称为弱引用。同样，释放Weak<T>也不意味着T被释放。这里的技巧是，强引用确实扩展了底层T的存活性——只有当Rc<T>的内部计数器达到零时，才会调用T的释放。在大多数情况下，很少需要弱引用，除非存在引用循环。假设要构建一个图结构，其中每个节点都持有对其连接节点的Rc<T>引用，并且图中存在循环。在当前节点上调用释放将递归地调用连接节点的释放，这将再次递归到当前节点，依此类推。如果图存储所有节点的向量，并且每个节点存储对连接的弱引用，那么向量的释放将导致所有节点被释放，无论是否存在循环。我们可以通过检查Rc<T>的Drop实现来了解这是如何在实际中工作的：

unsafe impl<#[may_dangle] T: ?Sized> Drop for Rc<T> {
    fn drop(&mut self) {
        unsafe {
            let ptr = self.ptr.as_ptr();

            self.dec_strong();
            if self.strong() == 0 {
                // destroy the contained object
                ptr::drop_in_place(self.ptr.as_mut());

                // remove the implicit "strong weak" pointer
                // now that we've destroyed the contents.
                self.dec_weak();

                if self.weak() == 0 {
                    Heap.dealloc(ptr as *mut u8, 
                    Layout::for_value(&*ptr));
                }
            }
        }
    }
}

这部分内容为了清晰起见进行了适当的缩减，但概念与我们描述的是一样的——当强引用的总数为零时，将发生完全的释放。被引用的Heap和Layout是编译器内部实现，这里不再进一步讨论，但有兴趣的读者被鼓励自行探索。回想一下在Rc<T>::new中，强引用和弱引用计数器都是从1开始的。为了避免使弱指针无效，只有当没有强引用或弱引用可用时，实际的T才会被释放。让我们再次看看Drop for Weak<T>，为了清晰起见，这里也进行了适当的缩减：

impl<T: ?Sized> Drop for Weak<T> {
    fn drop(&mut self) {
        unsafe {
            let ptr = self.ptr.as_ptr();

            self.dec_weak();
            // the weak count starts at 1, and will only go to
            // zero if all the strong pointers have disappeared.
            if self.weak() == 0 {
                Heap.dealloc(ptr as *mut u8, Layout::for_value(&*ptr));
            }
        }
    }
}

如预期的那样，只有当弱指针总数降至零时，T才能被释放，而这只有在没有剩余强指针的情况下才可能。这就是Rc<T>——一些重要的特性、一个专门的盒子和一些编译器内部实现。

Vec

作为本章的最后一个主题，让我们考虑Vec<T>。Rust 向量是一个可增长的数组，也就是说，一个连续、同质的存储区域，可以根据需要通过重新分配来增长，或者它可以缩小。与数组相比的优势在于不需要提前知道你需要多少存储空间，以及可切片结构和类型 API 中额外函数的所有好处。Vec<T>是一个非常常见的 Rust 结构，如此之多，以至于它的实际名称是std::vec::Vec<T>，但 Rust 默认导入此类型。Rust 程序充满了向量，因此理解它与所持内存的交互方式是很有道理的。

Vec<T>在src/liballoc/vec.rs中定义，如下所示：

pub struct Vec<T> {
    buf: RawVec<T>,
    len: usize,
}

Rust 文档声明，Vec<T>将按指针、usize容量和usize长度的顺序布局。这些字段的顺序完全未指定。正如我们之前讨论的，Rust 将根据需要重新排序字段。此外，指针保证不为空，允许进行空指针优化。之前，我们看到了 Rust 的常用技巧：用较低级（或原始）结构或甚至用完全不安全的结构来定义高级结构。我们已经看到了长度usize，称为len。这意味着容量和长度之间存在明显的区别，我们将在深入研究RawVec<T>时回到这一点。让我们看一下定义在src/liballoc/raw_vec.rs中的RawVec<T>：

pub struct RawVec<T, A: Alloc = Heap> {
    ptr: Unique<T>,
    cap: usize,
    a: A,
}

我们拥有的是一个指向Unique<T>的指针，这是一个添加了额外保证的*mut T，即RawVec<T>是唯一拥有分配的持有者，且指针不为空。cap是原始向量的容量。a: A是分配器，默认为Heap。Rust 允许交换分配器，只要实现遵守——截至撰写本书时——std::heap::Alloc特质。交换分配器是 Rust 的一个不稳定特性，仅在夜间频道中可用，但足够稳定，足以在嵌入式 Rust 社区的库中看到其常见使用。在这本书中，我们不会使用除默认分配器以外的任何东西，但强烈鼓励读者更深入地探索这个主题。抛开分配器不谈，还有 Rust 文档承诺的指针、长度和容量。让我们回到Vec<T>，看看new：

    pub fn new() -> Vec<T> {
        Vec {
            buf: RawVec::new(),
            len: 0,
        }
    }

现在，让我们看看原始vec的new：

    pub fn new() -> Self {
        Self::new_in(Heap)
    }

这将创建推迟到new_in，这是同一trait上的一个函数：

    pub fn new_in(a: A) -> Self {
        // !0 is usize::MAX. This branch should be stripped 
        // at compile time.
        let cap = if mem::size_of::<T>() == 0 { !0 } else { 0 };

        // Unique::empty() doubles as "unallocated" and "zero-sized
        // allocation"
        RawVec {
            ptr: Unique::empty(),
            cap,
            a,
        }
    }

cap计算很有趣。在Vec<T>——以及扩展的RawVec<T>——中可以存储一个T，其大小为零。实现者知道这一点，并提出了一种有趣的方法：如果类型的大小为零，则将容量设置为usize::MAX，否则为 0。由于在达到容量之前就会耗尽内存，因此不可能将usize::MAX个元素塞入一个向量，现在可以区分零大小类型的案例，而无需引入枚举或标志变量。这是一个整洁的技巧。如果我们回到向量并检查with_capacity，我们会发现它委托给RawVec::with_capacity，它又委托给RawVec::allocate_in：

    fn allocate_in(cap: usize, zeroed: bool, mut a: A) -> Self {
        unsafe {
            let elem_size = mem::size_of::<T>();

            let alloc_size = 
            cap.checked_mul(elem_size).expect("capacity overflow");
            alloc_guard(alloc_size);

            // handles ZSTs and `cap = 0` alike
            let ptr = if alloc_size == 0 {
                mem::align_of::<T>() as *mut u8
            } else {
                let align = mem::align_of::<T>();
                let result = if zeroed {
                    a.alloc_zeroed(Layout::from_size_align(
                        alloc_size, align).unwrap())
                } else {
                    a.alloc(Layout::from_size_align(
                        alloc_size, align).unwrap())
                };
                match result {
                    Ok(ptr) => ptr,
                    Err(err) => a.oom(err),
                }
            };

            RawVec {
                ptr: Unique::new_unchecked(ptr as *mut _),
                cap,
                a,
            }
        }
    }

这里有很多事情在进行中，但这是非常重要的，所以让我们将其分解成小块。首先，看看以下内容：

            let elem_size = mem::size_of::<T>();

            let alloc_size = 
            cap.checked_mul(elem_size).expect("capacity overflow");
            alloc_guard(alloc_size);

在函数的开头，计算了元素的大小，并确认调用者请求的总分配量不超过可用的系统内存。注意，checked_mul确保我们不会溢出 usize 并意外分配过少的内存。最后，调用了一个名为alloc_guard的函数。如下所示：

fn alloc_guard(alloc_size: usize) {
    if mem::size_of::<usize>() < 8 {
        assert!(
            alloc_size <= ::core::isize::MAX as usize,
            "capacity overflow"
        );
    }
}

这是一个保证检查。记住，usize 和 isize 是系统指针的带符号和无符号大小。为了理解这个保护措施，我们必须了解两个问题的答案：

1. 在给定的机器上，我能分配多少内存？

2. 在给定的机器上，我能访问多少内存？

可以从操作系统分配 usize 字节，但在这里，Rust 正在检查分配的大小是否小于 isize 的最大值。Rust 参考（doc.rust-lang.org/stable/reference/types.html#machine-dependent-integer-types）解释了原因：

"isize 类型是一个与平台指针类型位数相同的有符号整数类型。对象和数组大小的理论上限是 isize 的最大值。这确保了 isize 可以用来计算指向对象或数组的指针之间的差异，并且可以访问对象内的每个字节以及末尾之后的一个字节。"

结合checked_mul的容量检查，我们知道分配的大小是合适的，并且在整个分配中都是可寻址的：

            let ptr = if alloc_size == 0 {
                mem::align_of::<T>() as *mut u8
            } else {

如果所需的容量为零或T的大小为零，则实现将T的最小对齐方式强制转换为指向字节的指针，即*mut u8。这个指针，嗯，它指向没有用的地方，但实现避免了在没有可以分配的内容时进行分配，无论是由于零大小类型而永远不会分配，还是其他原因。这是好的，并且实现只需要意识到，当容量为零或类型大小为零时，指针不能被解引用。正确：

            } else {
                let align = mem::align_of::<T>();
                let result = if zeroed {
                    a.alloc_zeroed(Layout::from_size_align(alloc_size, 
                        align).unwrap())
                } else {
                    a.alloc(Layout::from_size_align(alloc_size, 
                        align).unwrap())
                };
                match result {
                    Ok(ptr) => ptr,
                    Err(err) => a.oom(err),
                }
            };

当需要分配内存时，会触发此分支。值得注意的是，有两个子可能性，由zeroed参数控制：要么内存被初始化为零，要么它保持未初始化状态。Vec<T>不向最终用户公开此选项，但我们通过检查知道内存开始时是未初始化的，这是一种对非平凡分配的优化：

            RawVec {
                ptr: Unique::new_unchecked(ptr as *mut _),
                cap,
                a,
            }
        }
    }

在某些情况下，缺乏初始化标志有点棘手。考虑std::io::Read::read_exact这个函数。它接受一个&mut [u8]，并且通常是从特别创建的 vec 中创建这个切片。以下代码将不会读取 1024 字节：

use std::io;
use std::io::prelude::*;
use std::fs::File;

let mut f = File::open("foo.txt")?;
let mut buffer = Vec:with_capacity(1024);

f.read_exact(&mut buffer)?;

为什么？我们传递的切片实际上长度为零！Rust 的解引用允许通过两个特质：std::ops::Deref和std::ops::DerefMut，这取决于你对不可变或可变切片的需求。Deref特质定义为以下：

pub trait Deref {
    type Target: ?Sized;
    fn deref(&self) -> &Self::Target;
}

以及可变版本的类似操作。当我们像前面的代码块那样切片我们的向量时，我们调用这个DerefMut::deref：

impl<T> ops::DerefMut for Vec<T> {
    fn deref_mut(&mut self) -> &mut [T] {
        unsafe {
            let ptr = self.buf.ptr();
            assume(!ptr.is_null());
            slice::from_raw_parts_mut(ptr, self.len)
        }
    }
}

这是非常重要的部分：slice::from_raw_parts_mut(ptr, self.len)。向量切片是通过长度构建的，而不是容量。向量的容量用于区分已分配的内存与已初始化的内存，无论是初始化为零还是插入其他值。这是一个重要的区别。我们有可能自行初始化内存：

let mut buffer: Vec<u8> = Vec::with_capacity(1024);
for _ in 0..1024 {
  buffer.push(0);
}
assert_eq!(1024, buffer.len());

或者依赖Vec API 从固定大小的数组转换：

let buffer = [0; 1024];
let buffer = &mut buffer.to_vec();
assert_eq!(1024, buffer.len());
}

两种方法都可行。你选择哪种取决于你是否提前知道缓冲区的大小。

对于这样一个重要的类型，Vec<T>上有许多 API 函数。在本章的剩余部分，我们将关注两个变异：push和insert。push函数是一个常数操作，除了任何必要的重新分配来应对容量限制达到的情况。以下是push函数：

    pub fn push(&mut self, value: T) {
        // This will panic or abort if we would allocate > isize::MAX bytes
        // or if the length increment would overflow for zero-sized types.
        if self.len == self.buf.cap() {
            self.buf.double();
        }
        unsafe {
            let end = self.as_mut_ptr().offset(self.len as isize);
            ptr::write(end, value);
            self.len += 1;
        }
    }

如果你还记得，self.buf是底层的RawVec<T>。Vec<T>的文档指出，当需要重新分配时，底层内存将加倍，这实际上是由RawVec<T>::double函数处理的。该函数相当长，并且正如你可能猜到的，它包含一系列计算新加倍大小的算术，并在存在现有分配时执行 realloc，否则在存在新分配时。这是值得列出的：

                None => {
                    // skip to 4 because tiny Vec's are dumb; 
                    // but not if that would cause overflow
                    let new_cap = if elem_size > (!0) / 8 { 
                                      1 
                                  } else { 
                                      4 
                                  };
                    match self.a.alloc_array::<T>(new_cap) {
                        Ok(ptr) => (new_cap, ptr),
                        Err(e) => self.a.oom(e),
                    }
                }

Alloc::alloc_array为连续内存分配空间，这适合容纳new_cap个大小为T的元素，并返回新分配空间第一个地址的指针。那么，这就是Vec<T>文档中承诺的连续内存！回到Vec<T>，现在容量至少是原来的两倍，值T可以插入：

        unsafe {
            let end = self.as_mut_ptr().offset(self.len as isize);
            ptr::write(end, value);
            self.len += 1;
        }

Rust 的指针很方便，因为它们的偏移函数会考虑到T的大小；调用者不需要做额外的乘法。实现是确定连续分配中第一个未使用的T大小空间——表示为end——然后将移动的T写入该地址。重要的是这个空间是未使用的，因为std::ptr::write不会释放可能原本存在于写入指针处的任何内存。如果你在活动引用上使用ptr::write，会发生奇怪的事情。

最后，是insert函数。Vec<T>的insert函数允许在向量的任何有效索引处插入T。如果插入到向量的末尾，该方法是功能上等同于推送的，尽管在机械上不同，我们很快就会看到。然而，如果插入发生在向量内部，则插入索引右侧的所有元素都会移动一次，这是一个依赖于分配大小的非平凡操作。以下是insert的完整列表：

    pub fn insert(&mut self, index: usize, element: T) {
        let len = self.len();
        assert!(index <= len);

        // space for the new element
        if len == self.buf.cap() {
            self.buf.double();
        }

        unsafe {
            // infallible
            // The spot to put the new value
            {
                let p = self.as_mut_ptr().offset(index as isize);
                // Shift everything over to make space. (Duplicating the
                // `index`th element into two consecutive places.)
                ptr::copy(p, p.offset(1), len - index);
                // Write it in, overwriting the first copy of the `index`th
                // element.
                ptr::write(p, element);
            }
            self.set_len(len + 1);
        }
    }

在本章的这个阶段，索引检查和潜在的缓冲是直接的。在unsafe块中，p是插入的正确偏移量。两条重要的行是：

ptr::copy(p, p.offset(1), len - index);
ptr::write(p, element);

当一个值被插入到向量中时，无论位置如何，从p开始到列表末尾的所有内存都会被复制到以p+1开始的内存上。一旦完成这个操作，插入的值就会覆盖p。这是一个非平凡的运算，可能会变得非常慢，尤其是如果需要移动的分配相当大时。以性能为导向的 Rust 会尽量少用，甚至不用Vec::insert。Vec<T>几乎肯定会出现在其中。

摘要

在本章中，我们介绍了 Rust 对象在内存中的布局，引用在安全和不安全 Rust 中的工作方式，并解决了 Rust 程序的多种分配策略。我们对 Rust 标准库中的类型进行了深入研究，以使这些概念具体化，并希望读者现在会感到舒适地进一步探索编译器，并充满信心地这样做。

进一步阅读

编程语言的内存模型是一个广泛的话题。截至撰写本书时，Rust 的内存模型必须通过检查 Rust 文档、rustc 源代码和对 LLVM 的研究来理解。也就是说，Rust 的内存模型没有正式的文档，尽管社区中有人提出要提供它。独立于这一点，对于工作的程序员来说，理解底层机器也很重要。有大量的材料需要覆盖。

这些笔记是一个小的开始，特别关注与本章最相关的 Rust 文档：

• 高性能代码 201：混合数据结构，作者：Chandler Carruth，可在www.youtube.com/watch?v=vElZc6zSIXM&index=5&list=PLKW_WLANyJtqQ6IWm3BjzHZvrFxFSooey找到。实际上，这是 2016 年 CppCon 的一次演讲。Carruth 是一位富有魅力的演讲者，他是专注于编译器性能的 LLVM 团队的一员。从构建与 CPU 缓存良好交互的信息密集型数据结构的角度来看，这次演讲特别有趣。尽管演讲是用 C++进行的，但其中的技术可以直接应用于 Rust。

• 无缓存感知算法，作者：Matteo Frigo, Charles Leiserson, Harald Prokop, 和 Sridhar Ramachandran。本文介绍了构建无缓存感知数据结构的概念，或者说是针对具有内存层次结构的机器的本地数据结构，以及如何与它们良好交互，此外还提供了一个机器模型来分析这样的数据结构。

• 无缓存感知算法与数据结构，作者：Erik Demaine。这篇论文是无缓存感知领域的经典之作，基于 Frigo 等人之前提出的工作，并对现有工作进行了总结。这是一篇非常值得阅读的论文，特别是与之前的论文结合阅读。浏览其参考文献也是很有价值的。

• 栈与堆，可在doc.rust-lang.org/book/first-edition/the-stack-and-the-heap.html找到。Rust 书的第一版中的这一章解释了硬件栈和堆之间的区别，以及各自的分配，以及这对 Rust 的影响。在某些方面，这一章已经进行了更深入的探讨，但强烈推荐 Rust 书中的这一章给任何需要复习或更温和地学习的人。

• 拆分借用，可在doc.rust-lang.org/beta/nomicon/borrow-splitting.html找到。Nomicon 是一本旨在教授低级 Rust 编程的 Rust 书籍，与这本书类似。虽然它还在不断完善中，但其中的信息非常有价值。“拆分借用”解释了新 Rust 开发者常见的一个问题：从向量或数组中执行多个可变借用。这种操作与结构体相关的事实常常是造成极大困惑和痛苦的原因。

• Rust 参考手册，可在doc.rust-lang.org/reference/找到。像任何成熟的编程语言一样，Rust 参考手册对于理解语言本身的微妙细节非常有价值，这些细节在多年的邮件列表和聊天中已经讨论过。当前形式的参考手册搜索起来可能有点困难——它曾经是一页长的单页文档——但希望在我们这本书付印时，情况会有所改善。

• 闭包：能够捕获其环境的匿名函数，可在doc.rust-lang.org/1.23.0/book/second-edition/ch13-01-closures.html找到。Rust 闭包对新手 Rust 开发者来说有一些微妙的影响，可能难以内化。在 Rust Book 的第二版中，这一章节在这方面做得非常出色。

• 外部块，可在doc.rust-lang.org/reference/items/external-blocks.html找到。在这本书中，外部块相对较少——也许在大多数你可能会看到的 Rust 代码中也是如此——但确实有一些可用。了解这份文档的存在是非常有价值的。

• 黑客的乐趣，亨利·沃伦小儿子著。这本书是经典之作。书中许多技巧现在作为一些芯片（如 x86）上的简单指令可用，但你仍会在rustc源代码中偶尔发现一些惊喜，尤其是swap_nonoverlapping_bytes技巧。

第四章：Sync 和 Send – Rust 并发的基石

Rust 旨在成为一个可以无畏地进行并发的编程语言。这意味着什么？它是如何工作的？在第二章，顺序 Rust 性能测试中，我们讨论了顺序 Rust 程序的性能，故意省略了对并发程序的讨论。在第三章，Rust 内存模型 – 所有权、引用和操作中，我们看到了 Rust 处理内存的概述，特别是关于构建高性能结构的方式。在本章中，我们将扩展我们之前学到的内容，并最终深入探讨 Rust 的并发故事。

到本章结束时，我们将：

• 讨论了Sync和Send特性

• 使用 Helgrind 检查了环形数据结构中的并行竞态

• 使用互斥锁解决了这个竞态条件

• 调查了标准库 MPSC 的使用

• 构建了一个非平凡的数据复用项目

技术要求

本章需要安装一个有效的 Rust 环境。验证安装的详细说明在第一章，预备知识 – 计算机架构和 Rust 入门中有所介绍。下面使用 Valgrind 工具套件。许多操作系统捆绑了 valgrind 包，但您可以在valgrind.org/找到您系统的进一步安装说明。Linux Perf 被使用，并且被许多 Linux 发行版捆绑。本章所需的其他任何软件都将作为文本的一部分安装。

您可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust/. 本章的源代码位于Chapter04目录下。

Sync 和 Send

并行 Rust 程序员必须理解两个关键特性——Send和Sync。Send特性应用于可以在线程边界之间传输的类型。也就是说，任何类型T: Send都可以安全地从一条线程移动到另一条线程。Rc<T>: !Send表示它被明确标记为在线程之间移动是不安全的。为什么？考虑如果它被标记为Send，会发生什么？我们从上一章知道Rc<T>是一个带有两个计数器的 boxed T，分别用于对T的弱引用和强引用。这些计数器是关键。假设我们将一个Rc<T>分散在两个线程——称为A和B——每个线程都创建了引用、丢弃了它们，等等。如果A和B同时丢弃了Rc<T>的最后一个引用，会发生什么？我们有两个线程之间的竞态，看哪个线程可以首先释放T，哪个线程会因此遭受双重释放的麻烦。更糟糕的是，假设在Rc<T>中的强引用计数器的获取被分散在三个伪指令中：

LOAD counter            (tmp)
ADD counter 1 INTO tmp  (tmp = tmp+1)
STORE tmp INTO counter  (counter = tmp)

同样地，假设一个强引用计数器的释放被分散到三个伪指令中：

LOAD counter            (tmp)
SUB counter 1 INTO tmp  (tmp = tmp-1)
STORE tmp INTO counter  (counter = tmp)

在单线程的上下文中，这工作得很好，但在多线程的上下文中考虑这个结果。在以下思维实验的开始，让所有线程的counter都等于 10：

[A]LOAD counter                        (tmp_a == 10)
[B]LOAD counter                        (tmp_b == 10)
[B]SUB counter 1 INTO tmp              (tmp_b = tmp_b-1)
[A]ADD counter 1 INTO tmp              (tmp_a = tmp_a + 1)
[A]STORE tmp INTO counter              (counter = tmp_a)    == 11
[A]ADD counter 1 INTO tmp              (tmp_a = tmp_a + 1)
[A]STORE tmp INTO counter              (counter = tmp_a)    == 12
[A]ADD counter 1 INTO tmp              (tmp_a = tmp_a + 1)
[A]STORE tmp INTO counter              (counter = tmp_a)    == 13
[B]STORE tmp INTO counter              (counter == tmp_b)   == 9

最后，我们失去了对Rc<T>的三个引用，这意味着虽然T在内存中没有丢失，但在我们删除T时，完全有可能在外部仍然有效但不再有效的内存中保留对其的引用，其结果是不确定的，但不太可能是好的。

Sync特质是从Send派生出来的，与引用有关：如果&T: Send，则T: Sync。也就是说，只有当共享一个&T，它表现得好像那个T被发送到线程中时，T才是Sync。从前面的代码中我们知道Rc<T>: !Send，因此我们也知道Rc<T>: !Sync。Rust 类型继承其组成部分的Sync和Send状态。按照惯例，任何Sync + Send的类型都被称为线程安全的。我们基于Rc<T>实现的任何类型都不会是线程安全的。现在，对于大多数情况，Sync和Send是自动派生的特质。在第三章中讨论的UnsafeCell不是线程安全的。同样，原始指针也不是，因为它们缺乏其他安全保证。当你探索 Rust 代码库时，你会发现一些特质在其他情况下会被自动派生为线程安全的，但被标记为不是。

竞态线程

你也可以将类型标记为线程安全的，这实际上是在向编译器承诺你已经以使它们安全的方式安排了所有数据竞争。这在实践中相对较少见，但在我们开始构建在安全原语之上之前，了解在 Rust 中使类型线程安全需要什么是有价值的。首先，让我们看看故意写错的代码：

use std::{mem, thread};
use std::ops::{Deref, DerefMut};

unsafe impl Send for Ring {}
unsafe impl Sync for Ring {}

struct InnerRing {
    capacity: isize,
    size: usize,
    data: *mut Option<u32>,
}

#[derive(Clone)]
struct Ring {
    inner: *mut InnerRing,
}

我们这里有一个环形，或者说是一个循环缓冲区，由u32组成。InnerRing包含一个原始可变指针，因此不是自动线程安全的。但是，我们已经向 Rust 承诺我们知道我们在做什么，并为Ring实现了Send和Sync。为什么不在InnerRing上呢？当我们从多个线程中操作内存中的对象时，该对象的位置必须固定。InnerRing——以及它包含的数据——必须在内存中占据一个稳定的位置。Ring可以并且将会在至少从创建线程到工作线程之间跳动。现在，InnerRing中的数据是什么？它是一个指向连续内存块 0 偏移量的指针，这个内存块将作为我们的循环缓冲区的存储。在撰写本书时，Rust 没有稳定的分配器接口，因此，为了获得连续的分配，我们必须以迂回的方式去做——将Vec<u32>简化为其指针：

impl Ring {
    fn with_capacity(capacity: usize) -> Ring {
        let mut data: Vec<Option<u32>> = Vec::with_capacity(capacity);
        for _ in 0..capacity {
            data.push(None);
        }
        let raw_data = (&mut data).as_mut_ptr();
        mem::forget(data);
        let inner_ring = Box::new(InnerRing {
            capacity: capacity as isize,
            size: 0,
            data: raw_data,
        });

        Ring {
            inner: Box::into_raw(inner_ring),
        }
    }
}

Ring::with_capacity函数与 Rust 生态系统中的其他类型的with_capacity函数非常相似：分配足够的空间以容纳容量项。在我们的情况下，我们利用Vec::with_capacity，确保为容量Option<u32>实例分配足够的房间，并在整个内存块长度上初始化为 None。如果你还记得第三章，《Rust 内存模型 – 所有权、引用和操作，这是作为Vec在分配上比较懒惰，而我们则需要分配。Vec::as_mut_ptr返回一个指向切片的原始指针，但不消耗原始对象，这对Ring来说是个问题。当数据超出作用域时，分配的块必须保持存活。标准库的mem::forget非常适合这种用途。现在分配是安全的，一个InnerRing被装箱以存储它。然后，这个箱子被Box::into_raw消耗，并传递给一个Ring。哇！

与具有内部原始指针的类型交互可能会很冗长，在周围散布不安全块，效果甚微。为此，Ring得到了Deref和DerefMut的实现，这两个实现都整理了与Ring的交互：

impl Deref for Ring {
    type Target = InnerRing;

    fn deref(&self) -> &InnerRing {
        unsafe { &*self.inner }
    }
}

impl DerefMut for Ring {
    fn deref_mut(&mut self) -> &mut InnerRing {
        unsafe { &mut *self.inner }
    }
}

现在我们已经定义了Ring，我们可以进入程序的实质部分。我们将定义两个将同时运行的运算——写入者和读取者。这里的想法是，写入者将在环中竞争，只要有机会就会写入，将u32值增加到环中。（在类型边界处，u32将回绕。）读取者将在写入者后面竞争，读取写入的值，检查每个读取的值是否比前一个读取的值大一个，但要注意回绕。以下是写入者：

fn writer(mut ring: Ring) -> () {
    let mut offset: isize = 0;
    let mut cur: u32 = 0;
    loop {
        unsafe {
            if (*ring).size != ((*ring).capacity as usize) {
                *(*ring).data.offset(offset) = Some(cur);
                (*ring).size += 1;
                cur = cur.wrapping_add(1);
                offset += 1;
                offset %= (*ring).capacity;
            } else {
                thread::yield_now();
            }
        }
    }
}

现在，为了非常清楚，这里有很多地方是错误的。目标是只在环缓冲区的大小未达到其容量时写入——这意味着有可用空间。实际的写入是：

                *(*ring).data.offset(offset) = Some(cur);
                (*ring).size += 1;

也就是说，我们取消引用ring (*ring)并得到指向Option<u32>大小块的指针，该块位于(*ring).data.offset(offset)，然后我们再次取消引用并将Some(cur)移动到之前的内容顶部。完全有可能因为Ring大小的竞争，我们会覆盖一个未读取的u32。写入块的其余部分设置我们的下一个cur和下一个偏移量，如果需要则加一并进行模运算：

            } else {
                thread::yield_now();
            }

thread::yield_now是新的。写入者是一个快速的旋转循环——它检查一个条件然后再次循环以进行另一次尝试。这非常不高效，对 CPU 和电力来说都是浪费。thread::yield_now向操作系统暗示这个线程没有工作要做，应该优先考虑其他线程。效果取决于操作系统和运行环境，但如果你必须旋转循环，那么让步仍然是一个好主意：

fn reader(mut ring: Ring) -> () {
    let mut offset: isize = 0;
    let mut cur: u32 = 0;
    while cur < 1_000 {
        unsafe {
            if let Some(num) = mem::replace(
                &mut *(*ring).data.offset(offset), 
                None) 
            {
                assert_eq!(num, cur);
                (*ring).size -= 1;
                cur = cur.wrapping_add(1);
                offset += 1;
                offset %= (*ring).capacity;
            } else {
                thread::yield_now();
            }
        }
    }
}

读取器与写入器类似，主要区别在于它不是一个无限循环。读取操作使用mem::replace完成，将读取偏移量处的块与None交换。当我们得到“bingo”并得到一个Some时，那个u32的内存现在归读取器所有——当它超出作用域时将调用drop。这是很重要的。写入器负责在原始指针内部丢失内存，而读取器负责找到它。通过这种方式，我们小心地避免内存泄漏。或者，好吧，我们会这样做，除非在Ring的大小上没有竞争。

最后，我们有main函数：

fn main() {
    let capacity = 10;
    let ring = Ring::with_capacity(capacity);

    let reader_ring = ring.clone();
    let reader_jh = thread::spawn(move || {
        reader(reader_ring);
    });
    let _writer_jh = thread::spawn(move || {
        writer(ring);
    });

    reader_jh.join().unwrap();
}

这里有两个新的情况。第一个是我们使用thread::spawn来启动一个reader和一个writer。move || {}结构被称为移动闭包。也就是说，闭包内部对外部作用域中每个变量的引用都被移动到闭包的作用域中。这就是为什么我们需要将环形克隆到reader_ring中。否则，就没有ring供写入器使用。第二个新情况是thread::spawn返回的JoinHandle。Rust 线程并没有与常见的 POSIX 或 Windows 线程有太大的不同。Rust 线程有自己的堆栈，并且可以由操作系统独立运行。

每个 Rust 线程都有一个返回值，尽管这里的返回值是()。我们通过在线程的JoinHandler上连接来获取这个返回值，暂停我们的线程的执行，直到线程成功完成或崩溃。我们的主线程假设其子线程将成功返回，因此有join().unwrap()。

当我们运行我们的程序时会发生什么？嗯，失败，这正是我们预期的：

> rustc -C opt-level=3 data_race00.rs && ./data_race00
thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
 left: `31`,
 right: `21`', data_race00.rs:90:17
 note: Run with `RUST_BACKTRACE=1` for a backtrace.
 thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any', libcore/result.rs:916:5

环形结构的缺陷

让我们来看看这里出了什么问题。我们的环形结构在内存中作为一个连续的块布局，并且我们在旁边挂了一些控制变量。以下是任何读取或写入发生之前系统的示意图：

size: 0
capacity: 5

 rdr
 |
|0: None |1: None |2: None |3: None |4: None |
 |
 wrt

以下是写入器写入第一个值后系统的示意图：

size: 0
capacity: 5

 rdr
 |
|0: Some(0) |1: None |2: None |3: None |4: None |
             |
             wrt

要做到这一点，作者进行了一系列关于大小和容量的负载测试，并在它们之间进行了比较，将结果写入块内的偏移量，并增加了大小。这些操作并不保证按照程序中的顺序执行，要么是因为推测性执行，要么是因为编译器重排序。正如我们在之前的运行示例中看到的，作者在其自己的写入上进行了覆盖，并且进展迅速。这是如何做到的？考虑在以下设置中，当读取器和写入器的执行被交错时会发生什么：

size: 5
capacity: 5

 rdr
 |
|0: Some(5) |1: Some(6) |2: Some(7) |3: Some(8) |4: Some(9) |
 |
 wrt

写入线程已经绕过环形结构两次，并处于环形结构的起始位置准备写入10。读者已经通过环形结构一次，并期待看到5。考虑一下如果读者的减小大小的操作在mem::replace之前进入主内存会发生什么。想象一下，如果这时写入线程被唤醒，正在检查其大小和容量。想象一下，除此之外，写入线程在读者再次醒来之前将其新的cur写入主内存。你会得到以下情况：

size: 5
capacity: 5

 rdr
 |
|0: Some(10) |1: Some(6) |2: Some(7) |3: Some(8) |4: Some(9) |
              |
              wrt

这是我们实际看到的情况。有时。在机器金属层面进行并发编程的技巧是：你正在处理概率。我们的程序成功运行或，更糟糕的是，在一个 CPU 架构上成功运行但在另一个架构上不成功运行是完全可能的。对这类程序进行随机测试和内省是至关重要的。实际上，在第一章，预备知识 – 机器架构和 Rust 入门中，我们讨论了一个valgrind套件工具helgrind，但当时并没有真正用到它。现在我们用到了。helgrind对我们故意制造的竞态条件程序有什么看法？

我们将这样运行helgrind：

> valgrind --tool=helgrind --history-level=full --log-file="results.txt" ./data_race00

这将打印出程序的完整历史，但将结果放在磁盘上的文件中以便更容易检查。以下是部分输出：

==19795== ----------------------------------------------------------------
==19795==
==19795== Possible data race during write of size 4 at 0x621A050 by thread #3
==19795== Locks held: none
==19795==    at 0x10F8E2: data_race00::writer::h4524c5c44483b66e (in /home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/data_races/data_race00)
==19795==    by 0x10FE75: _ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17ha5ca0c09855dd05fE.llvm.5C463C64 (in /home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/data_races/data_race00)
==19795==    by 0x12668E: __rust_maybe_catch_panic (lib.rs:102)
==19795==    by 0x110A42: _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h6b5d5a2a83058684 (in /home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/data_races/data_race00)
==19795==    by 0x1191A7: call_once<(),()> (boxed.rs:798)
==19795==    by 0x1191A7: std::sys_common::thread::start_thread::hdc3a308e21d56a9c (thread.rs:24)
==19795==    by 0x112408: std::sys::unix::thread::Thread::new::thread_start::h555aed63620dece9 (thread.rs:90)
==19795==    by 0x4C32D06: mythread_wrapper (hg_intercepts.c:389)
==19795==    by 0x5251493: start_thread (pthread_create.c:333)
==19795==    by 0x5766AFE: clone (clone.S:97)
==19795==
==19795== This conflicts with a previous write of size 8 by thread #2
==19795== Locks held: none
==19795==    at 0x10F968: data_race00::reader::h87e804792f6b43da (in /home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/data_races/data_race00)
==19795==    by 0x12668E: __rust_maybe_catch_panic (lib.rs:102)
==19795==    by 0x110892: _$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$::call_box::h4b5b7e5f469a419a (in /home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/data_races/data_race00)
==19795==    by 0x1191A7: call_once<(),()> (boxed.rs:798)
==19795==    by 0x1191A7: std::sys_common::thread::start_thread::hdc3a308e21d56a9c (thread.rs:24)
==19795==    by 0x112408: std::sys::unix::thread::Thread::new::thread_start::h555aed63620dece9 (thread.rs:90)
==19795==    by 0x4C32D06: mythread_wrapper (hg_intercepts.c:389)
==19795==    by 0x5251493: start_thread (pthread_create.c:333)
==19795==    by 0x5766AFE: clone (clone.S:97)
==19795==  Address 0x621a050 is in a rw- anonymous segment
==19795==
==19795== ----------------------------------------------------------------

输出不如预期清晰，但 helgrind 正在警告我们关于我们已知的数据覆盖问题。鼓励读者亲自运行 helgrind 并检查整个历史。

让我们改善这种情况。显然，我们存在竞态条件读写的问题，但我们在写入者的行为上也有问题。它覆盖了自己的写操作，对此毫无察觉。通过调整写入者，我们可以停止无意中覆盖写操作，如下所示：

fn writer(mut ring: Ring) -> () {
    let mut offset: isize = 0;
    let mut cur: u32 = 0;
    loop {
        unsafe {
            if (*ring).size != ((*ring).capacity as usize) {
                assert!(mem::replace(&mut *(*ring).data.offset(offset), 
                Some(cur)).is_none());
                (*ring).size += 1;
                cur = cur.wrapping_add(1);
                offset += 1;
                offset %= (*ring).capacity;
            } else {
                thread::yield_now();
            }
        }
    }
}

之后，我们运行程序几次，发现以下情况：

> ./data_race01
thread '<unnamed>thread '' panicked at '<unnamed>assertion failed: mem::replace(&mut *(*ring).data.offset(offset), Some(cur)).is_none()' panicked at '', assertion failed: `(left == right)`
  left: `20`,
   right: `10`data_race01.rs', :data_race01.rs65::8517:
   17note: Run with `RUST_BACKTRACE=1` for a backtrace.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Any', libcore/result.rs:945:5

这很有趣！两个线程都因为相同的原因崩溃了。作者不适当地覆盖了一个写操作，而读者读取了它。

回到安全性

正如我们之前讨论的，前面的例子故意使用了低级且不安全的方法。我们如何使用 Rust 提供的工具构建类似的东西呢？这里有一个方法：

use std::{mem, thread};
use std::sync::{Arc, Mutex};

struct Ring {
    size: usize,
    data: Vec<Option<u32>>,
}

impl Ring {
    fn with_capacity(capacity: usize) -> Ring {
        let mut data: Vec<Option<u32>> = Vec::with_capacity(capacity);
        for _ in 0..capacity {
            data.push(None);
        }
        Ring {
            size: 0,
            data: data,
        }
    }

    fn capacity(&self) -> usize {
        self.data.capacity()
    }

    fn is_full(&self) -> bool {
        self.size == self.data.capacity()
    }

    fn emplace(&mut self, offset: usize, val: u32) -> Option<u32> {
        self.size += 1;
        let res = mem::replace(&mut self.data[offset], Some(val));
        res
    }

    fn displace(&mut self, offset: usize) -> Option<u32> {
        let res = mem::replace(&mut self.data[offset], None);
        if res.is_some() {
            self.size -= 1;
        }
        res
    }
}

fn writer(ring_lk: Arc<Mutex<Ring>>) -> () {
    let mut offset: usize = 0;
    let mut cur: u32 = 0;
    loop {
        let mut ring = ring_lk.lock().unwrap();
        if !ring.is_full() {
            assert!(ring.emplace(offset, cur).is_none());
            cur = cur.wrapping_add(1);
            offset += 1;
            offset %= ring.capacity();
        } else {
            thread::yield_now();
        }
    }
}

fn reader(read_limit: usize, ring_lk: Arc<Mutex<Ring>>) -> () {
    let mut offset: usize = 0;
    let mut cur: u32 = 0;
    while (cur as usize) < read_limit {
        let mut ring = ring_lk.lock().unwrap();
        if let Some(num) = ring.displace(offset) {
            assert_eq!(num, cur);
            cur = cur.wrapping_add(1);
            offset += 1;
            offset %= ring.capacity();
        } else {
            drop(ring);
            thread::yield_now();
        }
    }
}

fn main() {
    let capacity = 10;
    let read_limit = 1_000_000;
    let ring = Arc::new(Mutex::new(Ring::with_capacity(capacity)));

    let reader_ring = Arc::clone(&ring);
    let reader_jh = thread::spawn(move || {
        reader(read_limit, reader_ring);
    });
    let _writer_jh = thread::spawn(move || {
        writer(ring);
    });

    reader_jh.join().unwrap();
}

这与之前的竞争性程序非常相似。我们有环（Ring），它包含一个大小，并围绕Vec<Option<u32>>集操作。这次，vec没有被拆分成原始指针，环的实现也更加完善。实际上，在我们的前一个例子中，我们有可能提供更多的抽象实现——就像我们在 Rust 内部探索时所看到的那样——但是间接和不可安全是粗糙的组合。有时，间接的不可安全代码比直接的不可安全代码更难识别为有缺陷。无论如何，你会注意到在这个实现中Ring: !Send。相反，写入和读取线程在Arc<Mutex<Ring>>上操作。

排除法的安全性

让我们谈谈Mutex。互斥锁（Mutex）在线程之间提供互斥。Rust 的Mutex工作方式与来自其他编程语言的预期一致。任何调用Mutex锁的线程都会获取锁或者阻塞，直到持有互斥锁的线程将其解锁。锁的类型为lock(&self) -> LockResult<MutexGuard<T>>。这里有一个巧妙的技巧。LockResult<Guard>是Result<Guard, PoisonError<Guard>>。也就是说，获取互斥锁锁的线程实际上得到一个结果，成功时包含MutexGuard<T>，或者是一个中毒通知。当互斥锁的持有者崩溃时，Rust 会中毒其互斥锁，这种策略有助于防止只有一个线程崩溃的多线程传播继续运行。正因为如此，你会发现许多 Rust 程序不会检查锁调用的返回值，并立即展开它。MutexGuard<T>在释放时，会解锁互斥锁。一旦互斥锁被解锁，就不再可能访问其内部封装的数据，因此，一个线程无法与另一个线程进行不良交互。Mutex既是Sync也是Send，这很有道理。那么，为什么我们要用Arc包装我们的Mutex<Ring>呢？Arc<T>究竟是什么呢？

原子引用计数指针Arc<T>。如前所述，Rc<T>不是线程安全的，因为如果它被标记为线程安全，那么内部强/弱计数器之间会有竞争，就像在我们的故意竞争的程序中一样。Arc<T>建立在原子整数之上，我们将在下一章中更详细地介绍。现在只需说，Arc<T>能够作为引用计数指针工作，而不会在线程之间引入数据竞争。Arc<T>可以在Rc<T>可以使用的任何地方使用，除了这些原子整数不是免费的。如果你可以使用Rc<T>，那就使用它。无论如何，下一章将有更多关于这个话题的介绍。

为什么是Arc<Mutex<Ring>>？因为Mutex<Ring>可以移动但不能克隆。让我们看看Mutex内部的情况：

pub struct Mutex<T: ?Sized> {
    // Note that this mutex is in a *box*, not inlined into
    // the struct itself. Once a native mutex has been used 
    // once, its address can never change (it can't be 
    // moved). This mutex type can be safely moved at any time,
    // so to ensure that the native mutex is used correctly we
    // box the inner mutex to give it a constant address.
    inner: Box<sys::Mutex>,
    poison: poison::Flag,
    data: UnsafeCell<T>,
}

我们可以看到T可能或可能不是有大小，并且T被存储在名为sys::Mutex的UnsafeCell<T>旁边。Rust 运行的每个平台都会提供自己的互斥锁形式，因为这些通常与操作系统环境相关联。如果你查看rustc代码，你会发现sys::Mutex是系统依赖互斥锁实现的包装器。Unix实现位于src/libstd/sys/unix/mutex.rs中，它是一个围绕pthread_mutex_t的UnsafeCell，正如你所期望的那样：

pub struct Mutex { inner: UnsafeCell<libc::pthread_mutex_t> }

并非严格必要在系统依赖的基础上实现Mutex，正如我们在原子原语章节中构建自己的锁时将会看到的。一般来说，除非有充分的理由不这样做（比如教学目的），否则使用可用的和经过良好测试的组件是一个好主意。

现在，如果我们克隆Mutex<T>会发生什么呢？首先，我们需要为系统互斥锁分配新的内存，如果T本身是可克隆的，可能还需要一个新的UnsafeCell。新的系统互斥锁是真正的问题——线程必须在内存中的相同结构上同步。将Mutex放入Arc中可以解决这个问题。像克隆Rc一样，克隆Arc会创建对Mutex的新强引用。这些引用是不可变的。这怎么工作呢？首先，Arc内部的互斥锁永远不会改变。在 Rust 提供的抽象模型中，互斥锁本身没有内部状态，并且通过锁定线程并没有真正发生任何修改。当然，这实际上并不完全正确，通过检查我们可以发现。Rust 的Mutex之所以表现得这样，是因为它周围包围着系统依赖结构的内部UnsafeCell。Rust 的Mutex利用了UnsafeCell允许的内部可变性。互斥锁本身保持不可变，而内部T通过MutexGuard可变地引用。这在 Rust 的内存模型中是安全的，因为由于互斥排他，任何给定时间只有一个可变引用到T：

fn main() {
    let capacity = 10;
    let read_limit = 1_000_000;
    let ring = Arc::new(Mutex::new(Ring::with_capacity(capacity)));

    let reader_ring = Arc::clone(&ring);
    let reader_jh = thread::spawn(move || {
        reader(read_limit, reader_ring);
    });
    let _writer_jh = thread::spawn(move || {
        writer(ring);
    });

    reader_jh.join().unwrap();
}

我们将Ring包裹在一个Arc、Mutex层中，将其克隆给读者，并将其移动到写者那里。在这里，这是一个风格问题，但重要的是要意识到，如果主线程创建并克隆一个Arc到子线程中，那么Arc的内容仍然存活，至少在主线程存活期间是这样。例如，如果一个文件处理程序被保存在主线程的Arc中，克隆到临时启动的工人，然后没有被丢弃，那么文件处理程序本身将永远不会关闭。当然，这可能是也可能不是你的程序所期望的。读者被鼓励在自己的系统上确认这一点。

此外，程序在多次运行后成功完成。不幸的是，从理论上讲，它并不特别高效。锁定互斥锁不是免费的，尽管我们的线程操作很短——除了一个内存交换外，还有少量算术运算——当一个线程持有互斥锁时，另一个线程会愚蠢地等待。Linux perf 证明了这一点：

> perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses ./data_race02

 Performance counter stats for './data_race02':

        988.944526      task-clock (msec)         #    1.943 CPUs utilized
             8,005      context-switches          #    0.008 M/sec
               137      page-faults               #    0.139 K/sec
     2,836,237,759      cycles                    #    2.868 GHz 
     1,074,887,696      instructions              #    0.38  insn per cycle
       198,103,111      branches                  #  200.318 M/sec
         1,557,868      branch-misses             #    0.79% of all branches
        63,377,456      cache-references          #   64.086 M/sec
             3,326      cache-misses              #    0.005 % of all cache refs

       0.508990976 seconds time elapsed

在执行过程中只使用了 1.3 个 CPU。对于这样一个简单的程序，我们可能更倾向于采用最简单的方法。此外，由于存在内存屏障的缓存写入效应——互斥锁肯定是一种——选择互斥锁而不是细粒度锁定策略可能更便宜。最终，这取决于在开发时间、机器效率的需求以及定义所使用 CPU 的机器效率之间的权衡。我们将在后面的章节中看到一些这方面的内容。

使用 MPSC

我们从 Ring 的奇特角度出发，一开始就试图构建一个功能不正常的程序，然后稍后对其进行改进。在一个真正的程序中，目的和功能会逐渐偏离其起源，偶尔问一下软件作为一个抽象概念实际上做什么是有意义的。那么，Ring 实际上做什么呢？首先，它是有限的，这是众所周知的。它有一个固定的容量，读者/写入器对会小心地保持在那个容量内。其次，它是一个旨在由两个或更多线程操作的架构，这些线程有两个角色：读取和写入。Ring 是线程间传递u32的一种方式，按照它们被写入的顺序进行读取。

幸运的是，只要我们愿意只接受一个读取线程，Rust 的标准库就提供了一些东西来满足这个常见需求——std::sync::mpsc。多生产者单消费者队列是这样一个队列，其写入端——称为Sender<T>——可以被克隆并移动到多个线程中。读取线程——称为Receiver<T>——只能被移动。有Sender<T>和SyncSender<T>两种发送者变体。第一个代表无界 MPSC，这意味着通道将根据需要分配空间以容纳发送到其中的Ts。第二个代表有界 MPSC，这意味着通道的内部存储有一个固定的上限容量。虽然 Rust 文档将Sender<T>和SyncSender<T>描述为异步和同步，但这并不完全正确。SyncSender<T>::send如果没有可用空间，将会阻塞，但还有一个SyncSender<T>::try_send，它是一个类型为try_send(&self, t: T) -> Result<(), TrySendError<T>>的函数。可以在有限的内存中使用 Rust 的 MPSC，同时考虑到调用者必须有一个策略来处理无法放入空间中的输入。

我们的u32传递程序使用 Rust 的 MPSC 看起来像这样：

use std::thread;
use std::sync::mpsc;

fn writer(chan: mpsc::SyncSender<u32>) -> () {
    let mut cur: u32 = 0;
    while let Ok(()) = chan.send(cur) {
        cur = cur.wrapping_add(1);
    }
}

fn reader(read_limit: usize, chan: mpsc::Receiver<u32>) -> () {
    let mut cur: u32 = 0;
    while (cur as usize) < read_limit {
        let num = chan.recv().unwrap();
        assert_eq!(num, cur);
        cur = cur.wrapping_add(1);
    }
}

fn main() {
    let capacity = 10;
    let read_limit = 1_000_000;
    let (snd, rcv) = mpsc::sync_channel(capacity);

    let reader_jh = thread::spawn(move || {
        reader(read_limit, rcv);
    });
    let _writer_jh = thread::spawn(move || {
        writer(snd);
    });

    reader_jh.join().unwrap();
}

这个程序比我们之前的任何程序都要短，而且根本不会出现算术错误。SyncSender的发送类型是send(&self, t: T) -> Result<(), SendError<T>>，这意味着必须处理SendError以避免程序崩溃。SendError仅在 MPSC 通道的远程端断开连接时返回，就像在这个程序中当读取器达到其read_limit时会发生的那样。这个奇怪程序的性能特性并不像最后一个Ring程序那样快：

> perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses ./data_race03

 Performance counter stats for './data_race03':

        760.250406      task-clock (msec)   #    0.765 CPUs utilized
           200,011      context-switches    #    0.263 M/sec
               135      page-faults         #    0.178 K/sec
     1,740,006,788      cycles              #    2.289 GHz
     1,533,396,017      instructions        #    0.88  insn per cycle
       327,682,344      branches            #  431.019 M/sec
     741,095      branch-misses             #    0.23% of all branches
        71,426,781      cache-references    #   93.952 M/sec
          4,082      cache-misses          #  0.006 % of all cache refs

       0.993142979 seconds time elapsed

但它完全在误差范围内，尤其是在考虑到编程的简便性。有一点值得记住的是，MPSC 中的消息只在一个方向上流动：通道不是双向的。因此，MPSC 不适合请求/响应模式。将两个或更多 MPSC 层叠起来以实现这一点并不罕见，理解到单侧的单个消费者有时可能不合适。

一个遥测服务器

让我们构建一个描述性统计服务器。这些服务器以某种方式在组织内部频繁出现：需要一个能够消费事件、对这些事件进行某种描述性统计计算，然后将描述输出到其他系统的工具。我的工作项目 postmates/cernan (crates.io/crates/cernan)存在的正是为了在资源受限的设备上以规模满足这一需求，同时不将操作人员绑定到任何类型的管道。我们现在要构建的是一个迷你版的 cernan，其流程如下：

                                _--> high_filter --> cma_egress
                               /
  telemetry -> ingest_point ---
    (udp)                      \_--> low_filter --> ckms_egress

理念是从简单的 UDP 协议中提取telemetry，尽可能快地接收它以避免操作系统丢弃数据包，然后通过高、低过滤器将这些点传递出去，最后将过滤后的点交给两个不同的统计egress点。与高过滤器相关联的egress计算连续移动平均，而与低过滤器相关联的egress使用 postmates/quantiles (crates.io/crates/quantiles)库中的近似算法计算分位数摘要。

让我们深入探讨。首先，让我们看看项目的Cargo.toml文件：

[package]
name = "telem"
version = "0.1.0"

[dependencies]
quantiles = "0.7"
seahash = "3.0"

[[bin]]
name = "telem"
doc = false

简洁明了。我们像之前提到的那样，绘制分位数，以及 seahasher。Seahasher 是一种特别快的哈希器——但不是加密安全的——我们将将其替换到HashMap中。关于这一点，稍后会有更多介绍。我们的可执行文件被拆分到src/bin/telem.rs，因为这个项目是一个分割的库/二进制设置：

extern crate telem;

use std::{thread, time};
use std::sync::mpsc;
use telem::IngestPoint;
use telem::egress::{CKMSEgress, CMAEgress, Egress};
use telem::event::Event;
use telem::filter::{Filter, HighFilter, LowFilter};

fn main() {
    let limit = 100;
    let (lp_ic_snd, lp_ic_rcv) = mpsc::channel::<Event>();
    let (hp_ic_snd, hp_ic_rcv) = mpsc::channel::<Event>();
    let (ckms_snd, ckms_rcv) = mpsc::channel::<Event>();
    let (cma_snd, cma_rcv) = mpsc::channel::<Event>();

    let filter_sends = vec![lp_ic_snd, hp_ic_snd];
    let ingest_filter_sends = filter_sends.clone();
    let _ingest_jh = thread::spawn(move || {
        IngestPoint::init("127.0.0.1".to_string(), 1990, 
        ingest_filter_sends).run();
    });
    let _low_jh = thread::spawn(move || {
        let mut low_filter = LowFilter::new(limit);
        low_filter.run(lp_ic_rcv, vec![ckms_snd]);
    });
    let _high_jh = thread::spawn(move || {
        let mut high_filter = HighFilter::new(limit);
        high_filter.run(hp_ic_rcv, vec![cma_snd]);
    });
    let _ckms_egress_jh = thread::spawn(move || {
        CKMSEgress::new(0.01).run(ckms_rcv);
    });
    let _cma_egress_jh = thread::spawn(move || {
        CMAEgress::new().run(cma_rcv);
    });

    let one_second = time::Duration::from_millis(1_000);
    loop {
        for snd in &filter_sends {
            snd.send(Event::Flush).unwrap();
        }
        thread::sleep(one_second);
    }
}

这里有很多事情在进行。前八行是我们需要的库片段的导入。main的主体主要由设置我们的工作线程并将适当的通道喂给它们组成。注意，一些线程需要通道的多个发送端：

    let filter_sends = vec![lp_ic_snd, hp_ic_snd];
    let ingest_filter_sends = filter_sends.clone();
    let _ingest_jh = thread::spawn(move || {
        IngestPoint::init("127.0.0.1".to_string(), 1990, 
        ingest_filter_sends).run();
    });

这就是我们在 Rust MPSC 中使用扇出方式的方法。让我们看看IngestPoint，实际上它在src/ingest_point.rs中定义：

use event;
use std::{net, thread};
use std::net::ToSocketAddrs;
use std::str;
use std::str::FromStr;
use std::sync::mpsc;
use util;

pub struct IngestPoint {
    host: String,
    port: u16,
    chans: Vec<mpsc::Sender<event::Event>>,
}

IngestPoint是一个主机——根据ToSocketAddrs，可以是 IP 地址或 DNS 主机名，一个端口和一个mpsc::Sender<event::Event>的向量。内部类型是我们定义的：

#[derive(Clone)]
pub enum Event {
    Telemetry(Telemetry),
    Flush,
}

#[derive(Debug, Clone)]
pub struct Telemetry {
    pub name: String,
    pub value: u32,
}

telem有两种事件流经它——Telemetry来自IngresPoint，Flush来自主线程。Flush像系统的一个时钟滴答，允许项目的各个子系统跟踪时间而不需要参考墙上的时钟。在嵌入式程序中，用一些已知的脉冲来定义时间是很常见的，如果可能的话，我在并行编程中也尽量保持这一点。至少，将时间作为一个系统外部推动的属性有助于测试。无论如何，回到IngestPoint：

impl IngestPoint {
    pub fn init(
        host: String,
        port: u16,
        chans: Vec<mpsc::Sender<event::Event>>,
    ) -> IngestPoint {
        IngestPoint {
            chans: chans,
            host: host,
            port: port,
        }
    }

    pub fn run(&mut self) {
        let mut joins = Vec::new();

        let addrs = (self.host.as_str(), self.port).to_socket_addrs();
        if let Ok(ips) = addrs {
            let ips: Vec<_> = ips.collect();
            for addr in ips {
                let listener =
                    net::UdpSocket::bind(addr)
                        .expect("Unable to bind to UDP socket");
                let chans = self.chans.clone();
                joins.push(thread::spawn(move || handle_udp(chans, 
                                                   &listener)));
            }
        }

        for jh in joins {
            jh.join().expect("Uh oh, child thread panicked!");
        }
    }
}

这里的第一部分，init，仅仅是设置。运行函数调用to_socket_addrs在我们的主机/端口对上，并检索所有相关的 IP 地址。每个这些地址都绑定一个UdpSocket和一个操作系统线程来监听从这个套接字来的数据报。这在线程开销方面是浪费的，在本书的后续部分我们将讨论基于事件的 IO 替代方案。之前讨论过的 Cernan，作为一个生产系统，在其源代码中使用了 Mio。这里的关键函数是handle_udp，这个函数被传递给新的监听线程。它如下所示：

fn handle_udp(mut chans: Vec<mpsc::Sender<event::Event>>, 
              socket: &net::UdpSocket) {
    let mut buf = vec![0; 16_250];
    loop {
        let (len, _) = match socket.recv_from(&mut buf) {
            Ok(r) => r,
            Err(e) => { 
                panic!(
                    format!("Could not read UDP socket with \
                            error {:?}", e)),
            }
        };
        if let Some(telem) = 
        parse_packet(str::from_utf8(&buf[..len]).unwrap()) {
            util::send(&mut chans, event::Event::Telemetry(telem));
        }
    }
}

这个函数是一个简单的无限循环，从套接字中拉取数据报到一个 16 KB 的缓冲区——比大多数数据报都要大得多——然后对结果调用parse_packet。如果数据报是我们尚未指定的协议的有效示例，那么我们就调用util::send来通过chans中的Sender<event::Event>发送Event::Telemetry。util::send不过是一个 for 循环：

pub fn send(chans: &[mpsc::Sender<event::Event>], event: event::Event) {
    if chans.is_empty() {
        return;
    }

    for chan in chans.iter() {
        chan.send(event.clone()).unwrap();
    }
}

消费负载没有什么特别之处：一个非空白字符的名字，后面跟着一个或多个空白字符，然后是一个u32，所有字符串都是字符串编码和 utf8 有效的：

fn parse_packet(buf: &str) -> Option<event::Telemetry> {
    let mut iter = buf.split_whitespace();
    if let Some(name) = iter.next() {
        if let Some(val) = iter.next() {
            match u32::from_str(val) {
                Ok(int) => {
                    return Some(event::Telemetry {
                        name: name.to_string(),
                        value: int,
                    })
                }
                Err(_) => return None,
            };
        }
    }
    None
}

转到过滤器，HighFilter和LowFilter都是基于一个共同的Filter特质完成的，这个特质定义在src/filter/mod.rs中：

use event;
use std::sync::mpsc;
use util;

mod high_filter;
mod low_filter;

pub use self::high_filter::*;
pub use self::low_filter::*;

pub trait Filter {
    fn process(
        &mut self,
        event: event::Telemetry,
        res: &mut Vec<event::Telemetry>,
    ) -> ();

    fn run(
        &mut self,
        recv: mpsc::Receiver<event::Event>,
        chans: Vec<mpsc::Sender<event::Event>>,
    ) {
        let mut telems = Vec::with_capacity(64);
        for event in recv.into_iter() {
            match event {
                event::Event::Flush => util::send(&chans, 
                 event::Event::Flush),
                event::Event::Telemetry(telem) => {
                    self.process(telem, &mut telems);
                    for telem in telems.drain(..) {
                        util::send(&chans, 
                        event::Event::Telemetry(telem))
                    }
                }
            }
        }
    }
}

任何实现滤波器的类都需要提供自己的处理过程。这是默认运行函数在从Receiver<Event>中拉取Event并发现它是一个Telemetry时调用的函数。尽管高低通滤波器都没有使用它，但处理函数能够通过在传递的telems向量上推送更多内容来将新的Telemetry注入到流中。这就是 cernan 的可编程滤波器能够允许最终用户从 Lua 脚本中创建telemetry的原因。此外，为什么传递telems而不是让处理函数返回一个Telemetry向量呢？这样可以避免持续的小型分配。根据系统不同，线程之间的分配可能不会协调一致——这意味着在高负载情况下可能会出现神秘的暂停——因此，如果代码没有因为这样的关注而扭曲成某种奇怪的版本，那么尽可能避免它们是一种好的编程风格。

无论是低通滤波器还是高通滤波器，基本原理都是相同的。当点小于或等于一个预定义的限制时，低通滤波器会通过自身传递这个点，而高通滤波器则大于或等于这个限制。下面是LowFilter的定义，位于src/filter/low_filter.rs文件中：

use event;
use filter::Filter;

pub struct LowFilter {
    limit: u32,
}

impl LowFilter {
    pub fn new(limit: u32) -> Self {
        LowFilter { limit: limit }
    }
}

impl Filter for LowFilter {
    fn process(
        &mut self,
        event: event::Telemetry,
        res: &mut Vec<event::Telemetry>,
    ) -> () {
        if event.value <= self.limit {
            res.push(event);
        }
    }
}

Egress的出口定义与滤波器的方式类似，分为子模块和公共特质。特质存在于src/egress/mod.rs文件中：

use event;
use std::sync::mpsc;

mod cma_egress;
mod ckms_egress;

pub use self::ckms_egress::*;
pub use self::cma_egress::*;

pub trait Egress {
    fn deliver(&mut self, event: event::Telemetry) -> ();

    fn report(&mut self) -> ();

    fn run(&mut self, recv: mpsc::Receiver<event::Event>) {
        for event in recv.into_iter() {
            match event {
                event::Event::Telemetry(telem) => self.deliver(telem),
                event::Event::Flush => self.report(),
            }
        }
    }
}

交付函数的目的是为egress提供存储其Telemetry的功能。报告函数的目的是迫使Egress的实现者向外部世界发布他们的汇总Telemetry。我们两个Egress实现者——CKMSEgress和CMAEgress——只是打印它们的信息，但你可以想象一个Egress通过某种网络协议将信息发送到远程系统。实际上，这正是 cernan 的Sinks所做的事情，跨越许多协议和传输。让我们看看单个出口，因为它们都非常相似。CKMSEgress的定义位于src/egress/ckms_egress.rs文件中：

use egress::Egress;
use event;
use quantiles;
use util;

pub struct CKMSEgress {
    error: f64,
    data: util::HashMap<String, quantiles::ckms::CKMS<u32>>,
    new_data_since_last_report: bool,
}

impl Egress for CKMSEgress {
    fn deliver(&mut self, event: event::Telemetry) -> () {
        self.new_data_since_last_report = true;
        let val = event.value;
        let ckms = self.data
            .entry(event.name)
            .or_insert(quantiles::ckms::CKMS::new(self.error));
        ckms.insert(val);
    }

    fn report(&mut self) -> () {
        if self.new_data_since_last_report {
            for (k, v) in &self.data {
                for q in &[0.0, 0.25, 0.5, 0.75, 0.9, 0.99] {
                    println!("[CKMS] {} {}:{}", k, q, 
                             v.query(*q).unwrap().1);
                }
            }
            self.new_data_since_last_report = false;
        }
    }
}

impl CKMSEgress {
    pub fn new(error: f64) -> Self {
        CKMSEgress {
            error: error,
            data: Default::default(),
            new_data_since_last_report: false,
        }
    }
}

注意data: util::HashMap<String, quantiles::ckms::CKMS<u32>>。这个util::HashMap是一个类型别名，代表std::collections::HashMap<K, V, hash::BuildHasherDefault<SeaHasher>>，如前所述。在这里，散列的加密安全性不如散列速度重要，这就是我们选择SeaHasher的原因。在 crates 中有很多可用的替代散列器，能够根据你的用例进行交换是一个很酷的技巧。"quantiles::ckms::CKMS"是一种近似数据结构，由 Cormode 等人定义在《在数据流上有效计算偏斜分位数》一文中。许多摘要系统在有限空间内运行，但愿意容忍错误。CKMS 数据结构允许在保持分位数近似误差保证界限的同时进行点丢弃。关于数据结构的讨论超出了本书的范围，但实现很有趣，论文也写得非常好。无论如何，这就是错误设置的全部内容。如果你回到主函数，注意我们硬编码错误为 0.01，或者说，任何分位数摘要都保证在 0.01 内偏离真实值。

实话实说，就是这样了。我们刚刚走过了非平凡 Rust 程序的大部分内容，这个程序是围绕标准库中提供的 MPSC 抽象构建的。让我们稍微玩弄一下它。在一个 shell 中，启动telem：

> cargo run --release
   Compiling quantiles v0.7.0
   Compiling seahash v3.0.5
   Compiling telem v0.1.0 (file:///Users/blt/projects/us/troutwine/concurrency_in_rust/external_projects/telem)
    Finished release [optimized] target(s) in 7.16 secs
     Running `target/release/telem`

在另一个 shell 中，开始发送 UDP 数据包。在 macOS 上，你可以这样使用nc：

> echo "a 10" | nc -c -u 127.0.0.1 1990
> echo "a 55" | nc -c -u 127.0.0.1 1990

在 Linux 上的调用类似；你只需要小心不要等待响应即可。在原始 shell 中，你在一秒后应该看到如下输出：

[CKMS] a 0:10
[CKMS] a 0.25:10
[CKMS] a 0.5:10
[CKMS] a 0.75:10
[CKMS] a 0.9:10
[CKMS] a 0.99:10
[CKMS] a 0:10
[CKMS] a 0.25:10
[CKMS] a 0.5:10
[CKMS] a 0.75:55
[CKMS] a 0.9:55
[CKMS] a 0.99:55

由于这些点低于限制，它们已经通过了低过滤并进入了 CKMS egress。回到我们的另一个 shell：

> echo "b 1000" | nc -c -u 127.0.0.1 1990
> echo "b 2000" | nc -c -u 127.0.0.1 1990
> echo "b 3000" | nc -c -u 127.0.0.1 1990

在telem shell 中：

[CMA] b 1000
[CMA] b 1500
[CMA] b 2000

嗯，正如预期的那样。由于这些点超过了限制，它们已经通过了高过滤并进入了 CMA egress。只要没有点进来，telem应该几乎不消耗 CPU，大约每秒唤醒一次线程以进行刷新脉冲。内存消耗也将非常低，主要表现为IngestPoint中的大输入缓冲区。

这个程序存在一些问题。在许多地方，我们明确地在潜在的问题点上 panic 或 unwrap，而不是处理这些问题。虽然在生产程序中 unwrap 是合理的，但你应该非常确定你为你的程序爆炸的错误无法以其他方式处理。最令人担忧的是，程序没有背压的概念。如果IngestPoint能够比过滤器或egress更快地产生点，它们可以吸收线程之间的通道，从而保持空间分配。将程序稍作修改以使用mpsc::SyncSender将是合适的——一旦通道填满到容量，就会应用背压——但前提是删除点是可以接受的。鉴于摄取协议是 UDP，这几乎肯定是可以的，但读者可以想象一个它不会是这样的场景。Rust 的标准库在需要替代形式的背压的领域存在困难，但诚然，这些是相当晦涩的。如果你对阅读一个类似于telem但没有任何这里确定的问题的生产程序感兴趣，我强烈推荐 cernan 代码库。

总的来说，Rust 的 MPSC 在构建并行系统时是一个非常实用的工具。在本章中，我们构建了自己的缓冲通道 Ring，但这并不常见。除非你有相当专业的用例，否则你不会考虑不使用标准库的 MPSC 进行线程间基于通道的通信。在我们介绍更多 Rust 的基本并发原语之后，下一章我们将探讨这样一个用例。

摘要

在本章中，我们讨论了 Rust 并发的基石——Sync和Send。此外，我们开始探讨在 Rust 中使原语线程安全的原因以及如何使用这些原语构建并发结构。我们通过一个不正确同步的程序进行推理，展示了了解 Rust 内存模型以及像helgrind这样的工具如何帮助我们确定程序中出了什么问题。这对读者来说可能并不意外，这是一个非常繁琐的过程，而且很可能出错。在第五章，锁——Mutex, Condvar, Barriers 和 RWLock，我们将讨论 Rust 向程序员暴露的高级粗粒度同步原语。在第六章，原子——同步的原始元素，我们将讨论现代机器暴露的细粒度同步原语。

进一步阅读

安全的并发编程是一个非常广泛的话题，这里提供的进一步阅读建议反映了这一点。细心的读者会注意到，这些参考文献跨越了时间和方法，反映了机器和语言随时间发生的广泛变化。

• 《多处理器编程的艺术》，作者：Maurice Herlihy 和 Nir Shavit。这本书是关于多处理器算法的优秀入门书籍。由于作者假设 Java 环境——垃圾回收在实现回收方面是一个巨大的胜利，因此将应用系统语言变得有些困难。

• 《C++并发实战：实用多线程》，作者：Anthony Williams。这本书是 TAoMP 的绝佳伴侣，专注于 C++中类似结构的实现。虽然 C++和 Rust 之间需要翻译步骤，但与 Java 到 Rust 的跳跃相比，这并不是那么大的跳跃。

• 《LVars：基于格的数据结构用于确定性并行性》，作者：Lindsey Kuper 和 Ryan Newton。这本书展示了一种特定的并行构造方法，它受到当前机器的影响。然而，我们的当前模型可能过于复杂，将来可能会被视为过时，即使在没有牺牲原始性能的情况下，就像我们在转向基于虚拟机的语言时所做的那样。这篇论文提出了一种受近年来分布式算法研究影响的构造替代方案。它可能是或可能不是未来，但鼓励读者保持关注。

• 《ffwd：委托比你想的快得多》，作者：Sepideh Roghanchi，Jakob Eriksson，和 Nilanjana Basu。现代机器是奇怪的生物。从概念上讲，最快的数据结构是那种最小化工作线程等待时间的数据结构，通过快速执行指令来加速工作完成。但这并不完全是这样，正如这篇论文所展示的。作者通过仔细维护缓存局部性，能够超越那些理论上可能更快但线程间更积极共享的复杂结构。

• 《平坦组合与同步-并行性权衡》，作者：Danny Hendler，Itai Incze，和 Nir Shavit。与 ffwd 类似，作者们提出了一种构建并发结构的方法，这种方法依赖于线程间的粗粒度独占锁定和操作日志的周期性组合。与缓存的交互使得平坦组合比不与缓存优雅交互的更复杂的无锁/等待自由替代方案更快。

• 《新 Rustacean，e022：Send 和 Sync》，可在www.newrustacean.com/show_notes/e022/struct.Script.html找到。新 Rustacean 是一个针对所有水平 Rust 开发者的优秀播客。这一集与当前章节讨论的内容非常契合。强烈推荐。

• 有效计算数据流中的偏斜分位数，Graham Cormode, Flip Korn, S. Muthukrishnan, 和 Divesh Srivastava。这篇论文奠定了在电信中使用的 CKMS 结构。考察论文中概述的实现与库中发现的实现之间的差异是有教育意义的——基于链表的实现与跳表的一个变体。这种差异完全是由于缓存局部性考虑。

• Cernan 项目，多位开发者，可在github.com/postmates/cernan下以 MIT 许可证获取。Cernan 是一个事件多路复用服务器，是本章讨论的玩具电信的生产版本。截至撰写本书时，它由 14 人贡献了 17,000 行代码。已经仔细注意到了保持低资源消耗和高性能。我是这个项目的首席作者，本书中讨论的技术已应用于 Cernan。

第五章：锁定机制 – Mutex、Condvar、屏障和 RWLock

在本章中，我们将深入研究 hopper，它是第四章，Sync 和 Send – Rust 并发基础中 Ring 的成熟版本。hopper 处理背压——我们在 telem*中识别出的弱点——是在填满容量时阻塞，就像SyncSender一样。hopper 的特殊技巧是将其页面输出到磁盘。hopper 用户定义了 hopper 允许消耗多少内存空间，就像SyncSender一样，只是以字节为单位而不是T的总元素数。此外，当 hopper 的内存容量填满并需要页面输出到磁盘时，用户还可以配置消耗的磁盘字节数。MSPC 的其他属性保持不变，如有序交付、存储后保留数据等。

然而，在我们深入挖掘之前，我们需要介绍更多 Rust 的并发原语。我们将通过解决来自《信号量小书》的一些谜题来解释它们，由于 Rust 没有提供信号量，因此在某些地方可能会有些棘手。

到本章结束时，我们将：

• 讨论了 Mutex、Condvar、屏障和 RWLock 的目的和使用方法

• 调查了标准库中 MPSC 的磁盘后端特殊化版本 hopper

• 看到了如何在生产环境中应用 QuickCheck、AFL 和全面基准测试

技术要求

本章需要安装一个有效的 Rust 环境。验证安装的详细信息在第一章，预备知识 – 机器架构和 Rust 入门中有所介绍。不需要额外的软件工具。

您可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Rust-Concurrency/。本章的源代码位于Chapter05。

读取多个，写入独占锁——RwLock

考虑这样一种情况，你有一个资源，一次只能由一个线程进行操作，但可以被多个线程安全地查询——也就是说，你有多个读者和一个写者。虽然我们可以用Mutex来保护这个资源，但问题是互斥锁对它的锁定者没有区分；无论它们的意图如何，每个线程都将被迫等待。RwLock<T>是互斥锁概念的替代品，允许两种类型的锁——读锁和写锁。类似于 Rust 的引用，一次只能有一个写锁，但可以有多个读锁，且不包括写锁。让我们看一个例子：

use std::thread;
use std::sync::{Arc, RwLock};

fn main() {
    let resource: Arc<RwLock<u16>> = Arc::new(RwLock::new(0));

    let total_readers = 5;

    let mut reader_jhs = Vec::with_capacity(total_readers);
    for _ in 0..total_readers {
        let resource = Arc::clone(&resource);
        reader_jhs.push(thread::spawn(move || {
            let mut total_lock_success = 0;
            let mut total_lock_failure = 0;
            let mut total_zeros = 0;
            while total_zeros < 100 {
                match resource.try_read() {
                    Ok(guard) => {
                        total_lock_success += 1;
                        if *guard == 0 {
                            total_zeros += 1;
                        }
                    }
                    Err(_) => {
                        total_lock_failure += 1;
                    }
                }
            }
            (total_lock_failure, total_lock_success)
        }));
    }

    {
        let mut loops = 0;
        while loops < 100 {
            let mut guard = resource.write().unwrap();
            *guard = guard.wrapping_add(1);
            if *guard == 0 {
                loops += 1;
            }
        }
    }

    for jh in reader_jhs {
        println!("{:?}", jh.join().unwrap());
    }
}

这里的想法是，我们将有一个写线程在循环中旋转并递增一个共享资源——一个 u16。一旦 u16 被包装了 100 次，写线程将退出。同时，一定数量的读线程（total_readers）将尝试获取共享资源——一个 u16 的读锁，直到它达到零 100 次。本质上，我们在这里是在赌线程的顺序。程序通常会以以下结果退出：

(0, 100)
(0, 100)
(0, 100)
(0, 100)
(0, 100)

这意味着每个读线程从未失败地获取其读锁——没有写锁存在。也就是说，读线程在写线程之前被调度。我们的主函数只连接到读处理程序，所以写线程在我们退出时仍在写。有时，我们会遇到正确的调度顺序，并得到以下结果：

(0, 100)
(126143752, 2630308)
(0, 100)
(0, 100)
(126463166, 2736405)

在这个特定的例子中，第二个和最后一个读线程在写线程之后被调度，并设法捕捉到守卫不为零的时刻。回想一下，这对中的第一个元素是读线程无法获取读锁并被迫重试的总次数。第二个是获取锁的次数。总的来说，写线程执行了 (2¹⁸ * 100) ~= 2²⁴ 次写操作，而第二个读线程执行了 log_2 2630308 ~= 2²¹ 次读操作。这丢失了很多写操作，也许是可以接受的。但更令人担忧的是，这导致了大约 2²⁶ 次无用的循环。海平面正在上升，而我们像没有人需要为此而死一样燃烧着电力。

我们如何避免所有这些浪费的努力？嗯，像大多数事情一样，这取决于我们想要做什么。如果我们需要每个读者都能获取到每个写操作，那么 MPSC 是一个合理的选择。它看起来会是这样：

use std::thread;
use std::sync::mpsc;

fn main() {
    let total_readers = 5;
    let mut sends = Vec::with_capacity(total_readers);

    let mut reader_jhs = Vec::with_capacity(total_readers);
    for _ in 0..total_readers {
        let (snd, rcv) = mpsc::sync_channel(64);
        sends.push(snd);
        reader_jhs.push(thread::spawn(move || {
            let mut total_zeros = 0;
            let mut seen_values = 0;
            for v in rcv {
                seen_values += 1;
                if v == 0 {
                    total_zeros += 1;
                }
                if total_zeros >= 100 {
                    break;
                }
            }
            seen_values
        }));
    }

    {
        let mut loops = 0;
        let mut cur: u16 = 0;
        while loops < 100 {
            cur = cur.wrapping_add(1);
            for snd in &sends {
                snd.send(cur).expect("failed to send");
            }
            if cur == 0 {
                loops += 1;
            }
        }
    }

    for jh in reader_jhs {
        println!("{:?}", jh.join().unwrap());
    }
}

它将运行——一段时间——并打印出以下内容：

6553600
6553600
6553600
6553600
6553600

但如果每个读者不需要看到每个写操作，也就是说，只要读者没有错过所有写操作，那么错过写操作是可以接受的，我们就有选择了。让我们看看其中一个。

阻塞直到条件改变 —— 条件变量

一个选项是条件变量，或称 CONDition VARiable。条件变量是一种巧妙的方式来阻塞一个线程，直到某个布尔条件发生变化。一个困难是条件变量仅与互斥锁相关联，但在这个例子中，我们并不太在意这一点。

条件变量工作的方式是，在获取互斥锁之后，你将 MutexGuard 传递给 Condvar::wait，这将阻塞线程。其他线程可能通过这个过程，阻塞在相同的条件下。某个其他线程将获取相同的独占锁，并最终在条件变量上调用 notify_one 或 notify_all。第一个唤醒单个线程，第二个唤醒 所有 线程。条件变量可能会发生虚假唤醒，这意味着线程可能在没有收到通知的情况下离开其阻塞状态。因此，条件变量会在循环中检查其条件。但是，一旦条件变量唤醒，你 确实 保证持有互斥锁，这防止了虚假唤醒时的死锁。

让我们将我们的例子修改为使用condvar。实际上，这个例子中有很多内容，所以我们将它分解成几个部分：

use std::thread;
use std::sync::{Arc, Condvar, Mutex};

fn main() {
    let total_readers = 5;
    let mutcond: Arc<(Mutex<(bool, u16)>, Condvar)> =
        Arc::new((Mutex::new((false, 0)), Condvar::new()));

我们的序言与前面的例子相似，但设置已经相当奇怪。我们正在同步mutcond上的线程，它是一个Arc<(Mutex<(bool, u16)>, Condvar)>。Rust 的Condvar有点尴尬。将Condvar与多个互斥量关联是未定义的行为，但Condvar的类型中并没有使这成为不变量的东西。我们只需记住保持它们关联。为此，在元组中将Mutex和Condvar配对是很常见的，就像这里一样。现在，为什么是Mutex<(bool, u16)>？元组的第二个元素是我们的资源，这在其他例子中是常见的。第一个元素是一个布尔标志，我们用它作为信号表示有可用的写入。以下是我们的读取线程：

    let mut reader_jhs = Vec::with_capacity(total_readers);
    for _ in 0..total_readers {
        let mutcond = Arc::clone(&mutcond);
        reader_jhs.push(thread::spawn(move || {
            let mut total_zeros = 0;
            let mut total_wakes = 0;
            let &(ref mtx, ref cnd) = &*mutcond;

            while total_zeros < 100 {
                let mut guard = mtx.lock().unwrap();
                while !guard.0 {
                    guard = cnd.wait(guard).unwrap();
                }
                guard.0 = false;

                total_wakes += 1;
                if guard.1 == 0 {
                    total_zeros += 1;
                }
            }
            total_wakes
        }));
    }

直到total_zeros达到 100，读取线程会锁定互斥量，检查互斥量内的守卫以检查写入可用性，如果没有写入，就会在condvar上等待，放弃锁。然后读取线程会阻塞，直到调用notify_all——我们很快就会看到。每个读取线程都会争先恐后地重新获取锁。幸运的获胜者会注意到没有更多的写入要读取，然后执行我们在前面的例子中看到的正常流程。需要重复的是，每个从条件等待中唤醒的线程都在争先恐后地第一个重新获取互斥量。我们的读取者不合作，它会立即阻止其他读取线程发现资源可用。然而，它们仍然会意外地醒来并被迫再次等待。也许。读取线程还在与写入线程竞争获取锁。让我们看看写入线程：

    let _ = thread::spawn(move || {
        let &(ref mtx, ref cnd) = &*mutcond;
        loop {
            let mut guard = mtx.lock().unwrap();
            guard.1 = guard.1.wrapping_add(1);
            guard.0 = true;
            cnd.notify_all();
        }
    });

写入线程是一个无限循环，我们在一个未连接的线程中将其孤儿化。现在，完全有可能写入线程会获取锁，增加资源，通知等待的读取线程，放弃锁，然后在任何读取线程被调度之前立即重新获取锁以开始 while 过程。这意味着在读取线程足够幸运地注意到之前，资源为零的情况完全可能发生多次。让我们结束这个程序：

    for jh in reader_jhs {
        println!("{:?}", jh.join().unwrap());
    }
}

理想情况下，我们希望有一种双向性——我们希望写入者发出有读取的信号，而读取者发出有容量的信号。这很可疑地类似于上一章中的 Ring 通过其大小变量工作，当我们小心不要在该变量上竞争时。例如，我们可以在混合中添加另一个条件变量，这个变量是给写入者的，但这里并不是这样，程序因此受到影响。以下是其中一个运行实例：

7243473
6890156
6018468
6775609
6192116

呼吁！这比之前的例子中的循环要多得多。这并不是说条件变量很难使用——它们并不难——只是它们需要与其他原语一起使用。我们将在本章后面看到一个很好的例子。

阻塞直到全员到齐——障碍

障碍是一种同步设备，它会阻塞线程，直到预定义数量的线程在同一个障碍上等待。当障碍等待的线程醒来时，会宣布一个领导者——可以通过检查BarrierWaitResult来发现——但这并不提供调度优势。当您希望延迟线程在某个资源的不安全初始化之后时，障碍变得有用——比如一个在启动时没有线程安全性的 C 库的内部结构，或者需要强制参与线程在大约相同的时间开始临界区。后者是更广泛的类别，根据作者的实践经验。当使用原子变量编程时，您会遇到障碍有用的场景。此外，考虑一下为低功耗设备编写多线程代码。如今，在电源管理方面有两种可能的策略：将 CPU 扩展以满足要求，实时调整程序的运行时间，或者尽可能快地烧毁程序的一部分，然后关闭芯片。在后一种方法中，障碍正是您需要的原语。

更多互斥锁、条件变量和类似功能正在行动

承认，前几节的例子有点复杂。这种疯狂的背后有原因，我保证，但在我们继续之前，我想给你展示一些来自迷人的《信号量小书》的工作示例。如果你跳过了之前的文献注释，这本书是适合自学的一组并发谜题，因为这些谜题很有趣，并且附带很好的提示。正如标题所暗示的，这本书确实使用了信号量原语，而 Rust 没有。尽管如此，正如前一章提到的，我们将在下一章构建一个信号量。

火箭准备问题

这个谜题实际上并没有出现在《信号量小书》中，但它基于那里的一则谜题——4.5 节中的吸烟者问题。我个人认为香烟很恶心，所以我们稍微改一下措辞。想法是相同的。

我们总共有四个线程。一个线程是“生产者”，随机发布“燃料”、“氧化剂”或“宇航员”中的一个。剩下的三个线程是消费者，或者说是“火箭”，它们必须按照之前列出的顺序获取资源。如果火箭没有按照这个顺序获取资源，那么准备火箭是不安全的，而且如果没有全部三个资源，火箭就不能起飞。此外，一旦所有火箭都准备好了，我们想要开始 10 秒倒计时，只有在这之后火箭才能起飞。

我们解决方案的序言比平常要长一些，目的是为了将解决方案作为一个独立的单元：

use std::{thread, time};
use std::sync::{Arc, Barrier, Condvar, Mutex};

// NOTE if this were a crate, rather than a stand-alone
// program, we could and _should_ use the XorShiftRng
// from the 'rand' crate.
pub struct XorShiftRng {
    state: u32,
}

impl XorShiftRng {
    fn with_seed(seed: u32) -> XorShiftRng {
        XorShiftRng { state: seed }
    }

    fn next_u32(&mut self) -> u32 {
        self.state ^= self.state << 13;
        self.state ^= self.state >> 17;
        self.state ^= self.state << 5;
        return self.state;
    }
}

对于这个解决方案，我们并不真的需要出色的随机性——操作系统调度器已经注入了足够的随机性——但只需要一点小小的随机性。XorShift 就能满足这个要求。现在，对于我们的资源：

struct Resources {
    lock: Mutex<(bool, bool, bool)>,
    fuel: Condvar,
    oxidizer: Condvar,
    astronauts: Condvar,
}

结构体被一个 Mutex<(bool, bool, bool)> 保护，布尔值是一个标志，用来指示是否有资源可用。我们持有第一个标志表示 燃料，第二个 氧化剂，第三个 宇航员。结构体的其余部分是匹配每个这些资源关注的条件变量。生产者 是一个简单的无限循环：

fn producer(resources: Arc<Resources>) {
    let mut rng = XorShiftRng::with_seed(2005);
    loop {
        let mut guard = resources.lock.lock().unwrap();
        (*guard).0 = false;
        (*guard).1 = false;
        (*guard).2 = false;
        match rng.next_u32() % 3 {
            0 => {
                (*guard).0 = true;
                resources.fuel.notify_all()
            }
            1 => {
                (*guard).1 = true;
                resources.oxidizer.notify_all()
            }
            2 => {
                (*guard).2 = true;
                resources.astronauts.notify_all()
            }
            _ => unreachable!(),
        }
    }
}

在每次迭代中，生产者选择一个新的资源——rng.next_u32() % 3——并为该资源设置布尔标志，然后通知所有等待 燃料 条件变量的线程。同时，编译器和 CPU 可以自由地重新排序指令，而内存 notify_all 则像是一个因果门；代码中的所有内容在因果上都是先于之后的，同样，之后的也是如此。如果资源布尔翻转在通知之后，那么从等待线程的角度来看，唤醒将是虚假的，并且从生产者的角度来看，它将丢失。火箭 是简单的：

fn rocket(name: String, resources: Arc<Resources>, 
          all_go: Arc<Barrier>, lift_off: Arc<Barrier>) {
    {
        let mut guard = resources.lock.lock().unwrap();
        while !(*guard).0 {
            guard = resources.fuel.wait(guard).unwrap();
        }
        (*guard).0 = false;
        println!("{:<6} ACQUIRE FUEL", name);
    }
    {
        let mut guard = resources.lock.lock().unwrap();
        while !(*guard).1 {
            guard = resources.oxidizer.wait(guard).unwrap();
        }
        (*guard).1 = false;
        println!("{:<6} ACQUIRE OXIDIZER", name);
    }
    {
        let mut guard = resources.lock.lock().unwrap();
        while !(*guard).2 {
            guard = resources.astronauts.wait(guard).unwrap();
        }
        (*guard).2 = false;
        println!("{:<6} ACQUIRE ASTRONAUTS", name);
    }

    all_go.wait();
    lift_off.wait();
    println!("{:<6} LIFT OFF", name);
}

每个线程，就资源需求而言，都会等待生产者使其可用。正如讨论的那样，发生了一场争夺重新获取互斥锁的竞争，只有一个线程能够获得资源。最后，一旦所有资源都获得，就会遇到 all_go 障碍，以延迟任何在倒计时之前的线程。这里我们需要 main 函数：

fn main() {
    let all_go = Arc::new(Barrier::new(4));
    let lift_off = Arc::new(Barrier::new(4));
    let resources = Arc::new(Resources {
        lock: Mutex::new((false, false, false)),
        fuel: Condvar::new(),
        oxidizer: Condvar::new(),
        astronauts: Condvar::new(),
    });

    let mut rockets = Vec::new();
    for name in &["KSC", "VAB", "WSMR"] {
        let all_go = Arc::clone(&all_go);
        let lift_off = Arc::clone(&lift_off);
        let resources = Arc::clone(&resources);
        rockets.push(thread::spawn(move || {
            rocket(name.to_string(), resources, 
                   all_go, lift_off)
        }));
    }

    thread::spawn(move || {
        producer(resources);
    });

    all_go.wait();
    let one_second = time::Duration::from_millis(1_000);
    println!("T-11");
    for i in 0..10 {
        println!("{:>4}", 10 - i);
        thread::sleep(one_second);
    }
    lift_off.wait();

    for jh in rockets {
        jh.join().unwrap();
    }
}

注意，大致来说，函数的前半部分由障碍和资源或火箭线程组成。all_go.wait() 是有趣的地方。这个主线程已经生成了所有子线程，现在正阻塞在来自火箭线程的 all-go 信号上，这意味着它们已经收集了资源，并且也阻塞在同一个障碍上。完成这些后，发生倒计时，为解决方案增添一点风采；同时，火箭线程已经开始在 lift_off 障碍上等待。顺便提一下，值得注意的是，生产者仍在生产，消耗 CPU 和电力。一旦倒计时完成，火箭线程被释放，主线程与它们连接，允许它们打印告别信息，程序结束。输出将会有所不同，但这里有一个代表性的例子：

KSC    ACQUIRE FUEL
WSMR   ACQUIRE FUEL
WSMR   ACQUIRE OXIDIZER
VAB    ACQUIRE FUEL
WSMR   ACQUIRE ASTRONAUTS
KSC    ACQUIRE OXIDIZER
KSC    ACQUIRE ASTRONAUTS
VAB    ACQUIRE OXIDIZER
VAB    ACQUIRE ASTRONAUTS
T-11
  10
   9
   8
   7
   6
   5
   4
   3
   2
   1
VAB    LIFT OFF
WSMR   LIFT OFF
KSC    LIFT OFF

绳索桥问题

这个谜题出现在 《信号量小书》 中的 黑猩猩过河问题，第 6.3 节。Downey 指出，它是从 Tanenbaum 的 操作系统：设计与实现 中改编的，所以你在这里得到的是第三手资料。问题描述如下：

在南非克鲁格国家公园的某个地方有一个深峡谷，峡谷上只有一根横跨的绳子。狒狒可以通过手拉手的方式在绳子上荡过峡谷，但如果两只朝相反方向行进的狒狒在中间相遇，它们将会打斗并掉入峡谷死亡。此外，这根绳子只能承受 5 只狒狒的重量。如果有更多的狒狒同时站在绳子上，它将会断裂。假设我们可以教会狒狒使用信号量，我们希望设计一个具有以下特性的同步方案：

• 一旦狒狒开始过桥，就保证它能到达对岸而不会遇到朝相反方向行进的狒狒。

• 绳子上永远不会超过 5 只狒狒。"

我们的解决方案不使用信号量。相反，我们依赖类型系统来提供保证，依赖它来确保左行狒狒永远不会遇到右行狒狒。让我们深入探讨：

use std::thread;
use std::sync::{Arc, Mutex};

#[derive(Debug)]
enum Bridge {
    Empty,
    Left(u8),
    Right(u8),
}

我们在这里看到了通常的序言，然后是一个类型，Bridge。Bridge是问题陈述中绳桥的模型，可以是空的，也可以有左行狒狒或右行狒狒在上面；我们不需要通过标志和推断状态来调整，因为我们可以直接将其编码到类型中。事实上，依赖类型系统，我们的同步非常简单：

fn main() {
    let rope = Arc::new(Mutex::new(Bridge::Empty));

只需要一个互斥锁。我们将桥的每一侧表示为一个线程，每一侧都试图让自己的狒狒过桥，但合作地允许狒狒到达其一侧。这里是桥的左侧：

    let lhs_rope = Arc::clone(&rope);
    let lhs = thread::spawn(move || {
        let rope = lhs_rope;
        loop {
            let mut guard = rope.lock().unwrap();
            match *guard {
                Bridge::Empty => {
                    *guard = Bridge::Right(1);
                }
                Bridge::Right(i) => {
                    if i < 5 {
                        *guard = Bridge::Right(i + 1);
                    }
                }
                Bridge::Left(0) => {
                    *guard = Bridge::Empty;
                }
                Bridge::Left(i) => {
                    *guard = Bridge::Left(i - 1);
                }
            }
        }
    });

当桥的左侧发现桥本身是空的，就会派一只右行狒狒上路。进一步地，当左侧发现桥上已经有右行狒狒，且绳子的容量五只尚未达到，就会再派一只狒狒上路。左行狒狒从绳子上被接走，绳子上狒狒的总数减少。这里的特殊情况是Bridge::Left(0)的条款。尽管桥上还没有狒狒，但从技术上讲，如果桥的右侧在左侧之前被调度，它就会派一只狒狒上路，正如我们很快就会看到的。当然，我们可以使移除狒狒的操作更加积极，并在没有旅行者时立即将桥设置为Bridge::Empty。以下是桥的右侧，与左侧类似：

    let rhs = thread::spawn(move || loop {
        let mut guard = rope.lock().unwrap();
        match *guard {
            Bridge::Empty => {
                *guard = Bridge::Left(1);
            }
            Bridge::Left(i) => {
                if i < 5 {
                    *guard = Bridge::Left(i + 1);
                }
            }
            Bridge::Right(0) => {
                *guard = Bridge::Empty;
            }
            Bridge::Right(i) => {
                *guard = Bridge::Right(i - 1);
            }
        }
    });

    rhs.join().unwrap();
    lhs.join().unwrap();
}

现在，这是公平的吗？这取决于你的系统互斥锁。一些系统提供了公平的互斥锁，即如果一个线程反复获取锁并饿死尝试锁定相同原语的其他线程，那么贪婪的线程将在其他线程之下被降级。这种公平性在锁定时可能会或可能不会产生额外的开销，具体取决于实现。实际上，你是否想要公平性，很大程度上取决于你试图解决的问题。如果我们只对尽可能快地将狒狒从绳索桥上运过去感兴趣——最大化吞吐量——那么它们来自哪个方向实际上并不重要。原始问题陈述没有提到公平性，它通过允许狒狒流是无限的来某种程度上打乱了这一点。考虑如果桥的两侧的狒狒是有限的，而我们想减少任何单个狒狒过桥到另一侧所需的时间，以最小化延迟会发生什么。我们目前的解决方案，适应有限流，在这方面相当差。通过偶尔让步、分层更积极的绳索打包、有意后退或其他众多策略，可以改善这种情况。一些平台允许你动态地改变线程相对于锁的优先级，但 Rust 的标准库并不提供这一点。

或者，你知道的，我们可以使用两个有界 MPSC 通道。这是一个选择。一切取决于你试图完成的事情。

最终，在安全的 Rust 中使用的工具对于在现有数据结构上执行计算非常有用，而无需涉及任何奇怪的业务。如果你是这样的游戏，你很可能不需要深入到Mutex和Condvar之外，可能还需要到RwLock和Barrier。但是，如果你正在构建由指针组成的结构，你将不得不深入研究我们在 Ring 中看到的那些奇怪的业务，以及它带来的所有危险。

Hopper——一个 MPSC 专业化

如上章末所述，你需要一个相当专业的用例来考虑不使用 stdlib 的 MPSC。在本章的其余部分，我们将讨论这样一个用例以及旨在填补这一空白的库的实现。

问题

回想一下上一章，其中 telem 中的角色线程通过 MPSC 通道相互通信。还要记住，telem 是 cernan (crates.io/crates/cernan)项目的快速版本，它基本上扮演了相同的角色，但覆盖了更多的入口协议、出口协议，并且边缘更加锋利。cernan 的一个关键设计目标是，如果它接收了你的数据，它至少会将它传递到下游一次。这意味着，为了支持入口协议，cernan 必须在其配置的路由拓扑的全长中知道，有足够的空间来接受一个新事件，无论它是一段遥测数据、原始字节数据缓冲区还是日志行。现在，这是可能的，正如我们所看到的，通过使用SyncSender。技巧在于与 cernan 的第二个设计目标相结合——非常低、可配置的资源消耗。您的作者看到 cernan 被部署到高可用性集群中，一个机器专门用于运行 cernan，以及 cernan 与应用程序服务器一起运行或作为 k8s 集群中 daemonset 的一部分。在前一种情况下，cernan 可以被配置为消耗机器的所有资源。在后两种情况下，需要考虑给 cernan 提供足够多的资源来完成其任务，相对于遥测系统的预期输入。

在现代系统中，通常有大量的磁盘空间和有限的——相对而言——RAM。使用SyncSender可能需要相对较少的可摄入事件或 cernan 可能消耗大量内存。这些情况通常发生在出口协议失败时，可能是因为远端系统关闭。如果 cernan 因为一个松散耦合系统中的故障而挤占了应用程序服务器，从而加剧了部分系统故障，那么，那将是非常糟糕的。

对于许多用户来说，在这样部分中断期间完全失去视线也是不可接受的。对于SyncSender来说，这是一个棘手的约束。实际上足够棘手，以至于我们决定编写我们自己的 MPSC，称为 hopper (crates.io/crates/hopper)。hopper 允许最终用户配置队列的总内存消耗，以字节为单位。这并不远，通过一些计算就可以达到SyncSender的水平。hopper 的特殊之处在于它可以分页到磁盘。

Hopper 在内存限制非常严格但又不希望丢弃事件的情况下表现突出。或者，你希望尽可能地将丢弃事件推迟。与内存队列类似，hopper 允许最终用户配置磁盘上可消耗的最大字节数。单个 hopper 队列在被迫丢弃事件之前，最多可以持有in_memory_bytes + on_disk_bytes字节；我们将在下面直接看到其确切机制。所有这些编程都是为了实现最大吞吐量和避免阻塞没有工作的线程，以节省 CPU 时间。

Hopper 的使用

在我们深入研究 hopper 的实现之前，看看它在实际中的应用将是有益的。让我们调整我们环形程序系列的最后一迭代。为了参考，这里看起来是这样的：

use std::thread;
use std::sync::mpsc;

fn writer(chan: mpsc::SyncSender<u32>) -> () {
    let mut cur: u32 = 0;
    while let Ok(()) = chan.send(cur) {
        cur = cur.wrapping_add(1);
    }
}

fn reader(read_limit: usize, chan: mpsc::Receiver<u32>) -> () {
    let mut cur: u32 = 0;
    while (cur as usize) < read_limit {
        let num = chan.recv().unwrap();
        assert_eq!(num, cur);
        cur = cur.wrapping_add(1);
    }
}

fn main() {
    let capacity = 10;
    let read_limit = 1_000_000;
    let (snd, rcv) = mpsc::sync_channel(capacity);

    let reader_jh = thread::spawn(move || {
        reader(read_limit, rcv);
    });
    let _writer_jh = thread::spawn(move || {
        writer(snd);
    });

    reader_jh.join().unwrap();
}

hopper 版本略有不同。这是前言：

extern crate hopper;
extern crate tempdir;

use std::{mem, thread};

没有什么意外的。将作为writer线程的功能是：

fn writer(mut chan: hopper::Sender<u32>) -> () {
    let mut cur: u32 = 0;
    while let Ok(()) = chan.send(cur) {
        cur = cur.wrapping_add(1);
    }
}

除了从mpsc::SyncSender<u32>切换到hopper::Sender<u32>——所有 hopper 发送者都是隐式有界的外——唯一的另一个区别是chan必须是可变的。现在，对于reader线程：

fn reader(read_limit: usize, 
          mut chan: hopper::Receiver<u32>) -> () {
    let mut cur: u32 = 0;
    let mut iter = chan.iter();
    while (cur as usize) < read_limit {
        let num = iter.next().unwrap();
        assert_eq!(num, cur);
        cur = cur.wrapping_add(1);
    }
}

这里还有更多的事情要做。在 hopper 中，接收者被设计成用作迭代器，这在某种程度上有些尴尬，因为我们想限制接收到的值的总数。迭代器在调用next时会阻塞，永远不会返回None。然而，hopper 中发送者的send与 MPSC 的非常不同——hopper::Sender<T>::send(&mut self, event: T) -> Result<(), (T, Error)>。先忽略Error，为什么在包含T的错误条件下返回一个元组？为了清楚起见，它是指传递进来的同一个T。当调用者将T发送到 hopper 时，它的所有权也传递给了 hopper，这在出错的情况下是个问题。调用者可能非常希望将T拿回来以避免其丢失。Hopper 想要避免对每个通过T都进行克隆，因此 hopper 偷偷地将T的所有权带回到调用者那里。那么Error呢？它是一个简单的枚举：

pub enum Error {
    NoSuchDirectory,
    IoError(Error),
    NoFlush,
    Full,
}

重要的是Error::Full。这是在发送时内存和基于磁盘的缓冲区都满了的情况。这个错误是可以恢复的，但只有调用者才能确定。现在，最后，我们的 hopper 示例的main函数：

fn main() {
    let read_limit = 1_000_000;
    let in_memory_capacity = mem::size_of::<u32>() * 10;
    let on_disk_capacity = mem::size_of::<u32>() * 100_000;

    let dir = tempdir::TempDir::new("queue_root").unwrap();
    let (snd, rcv) = hopper::channel_with_explicit_capacity::<u32>(
        "example",
        dir.path(),
        in_memory_capacity,
        on_disk_capacity,
        1,
    ).unwrap();

    let reader_jh = thread::spawn(move || {
        reader(read_limit, rcv);
    });
    let _writer_jh = thread::spawn(move || {
        writer(snd);
    });

    reader_jh.join().unwrap();
}

read_limit仍然在位，但最大的不同是通道的创建。首先，hopper 必须有一个地方来存放其磁盘存储。在这里，我们正在推迟到某个临时目录——let dir = tempdir::TempDir::new("queue_root").unwrap();——以避免在运行示例后进行清理。在实际使用中，磁盘位置会被仔细选择。hopper::channel_with_explicit_capacity创建的发送者与hopper::channel相同，除了所有配置旋钮都对调用者开放。第一个参数是通道的名称。这个值很重要，因为它将被用来在dir下创建一个用于磁盘存储的目录。通道名称必须是唯一的。in_memory_capacity和on_disk_capacity都是以字节为单位，这就是为什么我们使用了我们那位老朋友mem::size_of。现在，最后一个配置选项是什么，设置为1？那是队列文件的最大数量。

Hopper 的磁盘存储被分成多个队列文件，每个文件的大小为on_disk_capacity。发送者仔细协调他们的写入以避免队列文件过载，接收者负责在确定没有更多写入到来后销毁它们——我们将在本章后面讨论信号机制。使用队列文件允许 hopper 可能回收它可能无法通过使用一个大型文件以循环方式使用的情况下回收的磁盘空间。这确实会增加发送者和接收者代码的复杂性，但为了提供一个资源消耗更少的库，这是值得的。

hopper 的概念视图

在我们深入研究实现之前，让我们从概念层面了解一下之前的例子是如何工作的。我们有足够的内存空间来存储 10 个 u32。如果写入线程比读取线程快得多——或者获得更多的调度时间——我们可能会遇到这种情况：

write: 99

in-memory-buffer: [90, 91, 92, 93, 94, 95, 96, 97, 98]
disk-buffer: [87, 88, 89]

也就是说，当内存缓冲区完全满并且 diskbuffer 中有三个排队写入时，写入99正在进入系统。虽然世界状态可能在写入进入系统排队和排队之间发生变化，但让我们假设在排队期间没有接收者拉取项目。结果将是一个看起来像这样的系统：

in-memory-buffer: [90, 91, 92, 93, 94, 95, 96, 97, 98]
disk-buffer: [87, 88, 89, 99]

接收者总共必须从 diskbuffer 中读取三个元素，然后是所有内存中的元素，最后是从 diskbuffer 中读取一个元素，以保持队列的顺序。考虑到写入可能被接收者的一个或多个读取操作分割，这进一步增加了复杂性。我们在上一章中看到了类似的情况，即通过执行加载和检查来保护写入——满足检查的条件可能在加载、检查和操作之间发生变化。还有一个更复杂的因素；之前显示的统一磁盘缓冲区实际上并不存在。相反，可能存在许多单独的队列文件。

假设 hopper 已经被配置为允许 10 个u32的内存中配置，正如之前提到的，以及 10 个在磁盘上，但分布在五个可能的队列文件中。我们的修改后的写入系统如下：

in-memory-buffer: [90, 91, 92, 93, 94, 95, 96, 97, 98]
disk-buffer: [ [87, 88], [89, 99] ]

发送者负责创建队列文件并将它们填满到最大容量。Receiver负责从队列文件中读取，并在文件耗尽时删除该文件。确定队列文件耗尽机制的简单方法是：当Sender退出一个队列文件时，它将创建一个新的队列文件，并在文件系统中将旧路径标记为只读。当Receiver尝试从磁盘读取字节并发现没有字节时，它会检查文件的写入状态。如果文件仍然是读写状态，最终会有更多的字节到来。如果文件是只读的，则文件已耗尽。这里还有一些小技巧，以及Sender和Receiver之间未解释的进一步协作，但这应该足以让我们有效地深入研究。

双端队列（deque）

大致来说，hopper 是一个具有两个协作的有限状态机的并发双端队列。我们将从src/deque.rs中定义的双端队列开始。

下面的讨论列出了几乎所有的 hopper 源代码。我们将指出读者需要参考书中源代码仓库中的几个实例。

为了完全清楚，双端队列是一种数据结构，允许在队列的两端进行入队和出队操作。Rust 的stdlib有VecDeque<T>，这非常有用。然而，hopper 无法使用它，因为其设计目标之一是允许对 hopper 队列进行并行发送和接收，而VecDeque不是线程安全的。此外，尽管在 crate 生态系统中存在并发双端队列实现，但 hopper 双端队列与其支持的有限状态机以及 hopper 的内部所有权模型紧密相关。也就是说，你可能无法在不做任何修改的情况下在自己的项目中使用 hopper 的双端队列。无论如何，这里是一些前置说明：

use std::sync::{Condvar, Mutex, MutexGuard};
use std::sync::atomic::{AtomicUsize, Ordering};
use std::{mem, sync};

unsafe impl<T, S> Send for Queue<T, S> {}
unsafe impl<T, S> Sync for Queue<T, S> {}

这里唯一不熟悉的部分是从std::sync::atomic导入的内容。我们将在下一章更详细地介绍原子操作，但我们将根据需要以高级别概述它们。请注意，对于某些尚不为人知的类型Queue<T, S>，send和sync的声明是不安全的。我们即将进入非标准领域：

pub struct Queue<T, S> {
    inner: sync::Arc<InnerQueue<T, S>>,
}

Queue<T, S>的定义与我们之前章节中看到的是相似的：一个简单的结构封装了一个内部结构，这里称为InnerQueue<T, S>。InnerQueue被封装在一个Arc中，这意味着堆上只有一个分配的InnerQueue。正如你所期望的，Queue的克隆是将Arc复制到一个新的结构体中：

impl<T, S> Clone for Queue<T, S> {
    fn clone(&self) -> Queue<T, S> {
        Queue {
            inner: sync::Arc::clone(&self.inner),
        }
    }
}

重要的是，每个与Queue交互的线程都能看到相同的InnerQueue。否则，线程正在处理不同的内存区域，彼此之间没有关系。让我们看看InnerQueue：

struct InnerQueue<T, S> {
    capacity: usize,
    data: *mut Option<T>,
    size: AtomicUsize,
    back_lock: Mutex<BackGuardInner<S>>,
    front_lock: Mutex<FrontGuardInner>,
    not_empty: Condvar,
}

好吧，这更接近我们在 Rust 本身看到的内部结构，而且有很多事情在进行中。字段 capacity 是 InnerQueue 将在数据中保留的最大元素数量。就像前一章中的第一个 Ring 一样，InnerQueue 使用连续的内存块来存储其 T 元素，通过将 Vec 拆分来获得这个连续块。同样，就像第一个 Ring 一样，我们在连续的内存块中存储 Option<T> 元素。技术上，我们可以处理原始指针的连续块或复制内存块。但使用 Option<T> 简化了代码，无论是插入还是删除，但每个元素需要牺牲一个字节的内存。这种额外的复杂性对于 hopper 尝试达到的性能目标来说并不值得。

size 字段是一个原子 usize。原子将在下一章中详细介绍，但 size 的行为将非常重要。现在，将其视为线程之间非常小的同步机制；一个小的钩子，它将允许我们按顺序进行内存访问，同时也像 usize 一样操作。not_empty condvar 用于向任何等待新元素弹出的潜在读者发出信号，实际上确实有元素可以弹出。condvar 的使用大大减少了 hopper 的 CPU 负载，而没有牺牲对忙循环的延迟。现在，back_lock 和 front_lock。这里发生了什么？双端队列的每一侧都由互斥锁保护，这意味着一次只能有一个入队者和一个出队者，但它们可以相互并行运行。以下是互斥锁的两个内部值的定义：

#[derive(Debug, Clone, Copy)]
pub struct FrontGuardInner {
    offset: isize,
}

#[derive(Debug)]
pub struct BackGuardInner<S> {
    offset: isize,
    pub inner: S,
}

FrontGuardInner 是两个中较容易解释的。唯一的字段是 offset，它定义了从 InnerGuard 数据的第一个指针到操作队列前端的线程的偏移量。这种连续存储也以环形缓冲区的方式使用。在 BackGuardInner 中，我们看到相同的偏移量，但还有一个额外的 inner，S。这是什么？正如我们将看到的，操作缓冲区后端的线程需要它们之间的额外协调。这究竟是什么，队列并不关心。因此，我们将其作为类型参数，并允许调用者整理一切，同时小心地按需传递数据。以这种方式，队列通过自身传递状态，但不需要检查它。

让我们从 InnerQueue 的实现开始：

impl<T, S> InnerQueue<T, S>
where
    S: ::std::default::Default,
{
    pub fn with_capacity(capacity: usize) -> InnerQueue<T, S> {
        assert!(capacity > 0);
        let mut data: Vec<Option<T>> = Vec::with_capacity(capacity);
        for _ in 0..capacity {
            data.push(None);
        }
        let raw_data = (&mut data).as_mut_ptr();
        mem::forget(data);
        InnerQueue {
            capacity: capacity,
            data: raw_data,
            size: AtomicUsize::new(0),
            back_lock: Mutex::new(BackGuardInner {
                offset: 0,
                inner: S::default(),
            }),
            front_lock: Mutex::new(FrontGuardInner { offset: 0 }),
            not_empty: Condvar::new(),
        }
    }

该类型缺少一个 new() -> InnerQueue，因为没有必要调用它。相反，只有 with_capacity，这与我们之前看到的 Ring 的 with_capacity 非常相似——分配了一个向量，并将其拆分为原始指针，然后在指针加载到新创建的结构体之前，原始引用被遗忘。

类型 S 必须实现一个默认初始化，该初始化足够充分，因为调用者的走私状态总是相同的值，这可以充分定义为默认值。如果这个去队列打算用于通用用途，我们可能需要提供一个 with_capacity，它也直接接受 S。现在，我们快速浏览一下实现中的几个其他函数：

    pub fn capacity(&self) -> usize {
        self.capacity
    }

    pub fn size(&self) -> usize {
        self.size.load(Ordering::Relaxed)
    }

    pub fn lock_back(&self) -> MutexGuard<BackGuardInner<S>> {
        self.back_lock.lock().expect("back lock poisoned")
    }

    pub fn lock_front(&self) -> MutexGuard<FrontGuardInner> {
        self.front_lock.lock().expect("front lock poisoned")
    }

下一个函数 push_back 非常重要且微妙：

    pub unsafe fn push_back(
        &self,
        elem: T,
        guard: &mut MutexGuard<BackGuardInner<S>>,
    ) -> Result<bool, Error<T>> {
        let mut must_wake_dequeuers = false;
        if self.size.load(Ordering::Acquire) == self.capacity {
            return Err(Error::Full(elem));
        } else {
            assert!((*self.data.offset((*guard).offset)).is_none());
            *self.data.offset((*guard).offset) = Some(elem);
            (*guard).offset += 1;
            (*guard).offset %= self.capacity as isize;
            if self.size.fetch_add(1, Ordering::Release) == 0 {
                must_wake_dequeuers = true;
            }
        }
        Ok(must_wake_dequeuers)
    }

InnerQueue::push_back 负责将 T 放置在环形缓冲区的当前尾部，或者在容量不足时发出信号表示缓冲区已满。当我们讨论环形缓冲区时，我们注意到 size == capacity 检查是一个竞争条件。但在 InnerQueue 中不是这样，多亏了大小的原子性。self.size.load(Ordering::Acquire) 执行对 self.size 的内存加载，但确信它是唯一一个可以将 self.size 作为可操作值的线程。线程中的后续内存操作将在 Acquire 之后排序，至少直到发生 Ordering::Release 的存储操作。这种类型的存储操作就在几行之后发生——self.size.fetch_add(1, Ordering::Release)。在这两点之间，我们看到元素 T 被加载到缓冲区中——在之前检查确保我们不会覆盖一个 Some 值——并且对 BackGuardInner 的偏移量进行包装增加。就像在上一章中一样。这个实现的不同之处在于返回 Ok(must_wake_dequeuers)。因为内部 S 被保护，队列无法知道在可以放弃互斥锁之前是否需要做更多的工作。因此，队列本身无法发出有值可读的信号，尽管在函数返回时该值已经被写入内存。调用者必须运行通知。这是一个尖锐的边缘。如果调用者忘记通知在 condvar 上阻塞的线程，那么阻塞的线程将永远保持这种状态。

InnerQueue::push_front 比较简单，并且与 push_back 没有太大差异：

    pub unsafe fn pop_front(&self) -> T {
        let mut guard = self.front_lock.lock()
                            .expect("front lock poisoned");
        while self.size.load(Ordering::Acquire) == 0 {
            guard = self.not_empty
                .wait(guard)
                .expect("oops could not wait pop_front");
        }
        let elem: Option<T> = mem::replace(&mut 
        *self.data.offset((*guard).offset), None);
        assert!(elem.is_some());
        *self.data.offset((*guard).offset) = None;
        (*guard).offset += 1;
        (*guard).offset %= self.capacity as isize;
        self.size.fetch_sub(1, Ordering::Release);
        elem.unwrap()
    }
}

弹出前端的线程，因为它不需要协调，能够自己获取前端锁，因为没有需要通过线程传递的状态。在获取锁后，线程进入一个条件检查循环，以防止在 not_empty 上的虚假唤醒。当线程能够唤醒时，用 None 替换偏移量处的项目。通常的偏移量维护也会发生。

与内部结构相比，Queue<T, S> 的实现相当简单。以下是 push_back 的实现：

pub fn push_back(
    &self,
    elem: T,
    mut guard: &mut MutexGuard<BackGuardInner<S>>,
) -> Result<bool, Error<T>> {
    unsafe { (*self.inner).push_back(elem, &mut guard) }
}

Queue 中唯一实质上新的功能是 notify_not_empty(&self, _guard: &MutexGuard<FrontGuardInner>) -> ()。调用者负责在 push_back 信号指示需要通知去队列时调用此功能，并且尽管守卫未使用，但通过要求传入守卫，该库的一个粗糙边缘得到了平滑处理，证明它被持有。

这就是跳转器核心的双端队列。这个结构非常难以正确实现。任何对原子大小相对于其他内存操作的加载和存储的轻微重新排序都会引入错误，例如在没有协调的情况下对同一区域内存的并行访问。这些错误非常微妙，不会立即显现。在 x86 和 ARM 处理器上广泛使用 helgrind 加 quickcheck 测试——关于这一点稍后还会详细介绍——将有助于提高对实现的信心。测试运行数小时并不罕见，可以发现那些不是确定性的但可以通过足够的时间和重复示例进行推理的错误。从非常原始的组件构建并发数据结构是困难的。

接收器

既然我们已经涵盖了双端队列，让我们跳转到定义在 src/receiver.rs 中的 Receiver。如前所述，接收器负责以迭代器的风格从内存或磁盘中拉取值。Receiver 声明将自身转换为迭代器的通常机制，我们在这本书中不会涉及这一点，主要是因为它有点繁琐。话虽如此，Receiver 中有两个重要的函数需要介绍，而且它们都不在公共接口中。第一个是 Receiver::next_value，由接收器的迭代器版本调用。此函数定义如下：

fn next_value(&mut self) -> Option<T> {
    loop {
        if self.disk_writes_to_read == 0 {
            match self.mem_buffer.pop_front() {
                private::Placement::Memory(ev) => {
                    return Some(ev);
                }
                private::Placement::Disk(sz) => {
                    self.disk_writes_to_read = sz;
                    continue;
                }
            }
        } else {
            match self.read_disk_value() {
                Ok(ev) => return Some(ev),
                Err(_) => return None,
            }
        }
    }
}

定义为移动 T 值的跳转器并不定义一个在 Ts 上的双端队列——如前文所述——而是实际上它持有 Placement<T>。Placement 在 src/private.rs 中定义，是一个小的枚举：

pub enum Placement<T> {
    Memory(T),
    Disk(usize),
}

这就是使跳转器工作的小技巧。并发数据结构的主要挑战在于在线程之间提供足够的同步，以便您的结果可以在调度混乱的情况下保持一致性，但又不要求与顺序解决方案相比同步过多。

这种情况确实会发生。

现在，回想一下，保持顺序是任何通道式队列的关键设计需求。Rust 标准库的 MPSC 通过原子标志实现这一点，得益于最终只有一个地方可以存储插入的元素，以及一个地方可以从中移除。但在跳转器中并非如此。但是，这个一站式商店是一个非常有用且低同步的方法。这就是 Placement 发挥作用的地方。当遇到 Memory 变体时，T 已经存在，接收器只需返回它。当返回 Disk(usize) 时，这向接收器发送一个信号，使其切换到磁盘模式。在磁盘模式下，当 self.disk_writes_to_read 不为零时，接收器优先从磁盘读取一个值。只有当没有更多磁盘值可以读取时，接收器才会尝试再次从内存中读取。这种模式切换方法保持了顺序，同时也具有在磁盘模式下不需要同步的额外好处，这有助于在从慢速磁盘读取时节省关键时间。

需要检查的第二个重要函数是read_disk_value，它在next_value中被引用。这个函数很长，主要是记录，但我确实想在这里指出该函数的第一部分：

    fn read_disk_value(&mut self) -> Result<T, super::Error> {
        loop {
            match self.fp.read_u32::<BigEndian>() {
                Ok(payload_size_in_bytes) => {
                    let mut payload_buf = vec![0; payload_size_in_bytes 
                     as usize];
                    match self.fp.read_exact(&mut payload_buf[..]) {
                        Ok(()) => {
                            let mut dec = 
                            DeflateDecoder::new(&payload_buf[..]);
                            match deserialize_from(&mut dec) {
                                Ok(event) => {
                                    self.disk_writes_to_read -= 1;
                                    return Ok(event);
                                }
                                Err(e) => panic!("Failed decoding. 
                                Skipping {:?}", e),
                            }
                        }

这段小代码使用了两个非常实用的库。Hopper 将其磁盘上的元素以 bincode 格式存储到磁盘上。Bincode（crates.io/crates/bincode）是为 servo 项目发明的，是一个用于 IPC 的序列化库——几乎就是 hopper 用它来做的。bincode 的优点是序列化和反序列化速度快，但缺点是它不是一个标准，并且版本之间没有保证的二进制格式。需要指出的第二个库在这个例子中几乎看不见；byteorder。你可以在这里看到它：self.fp.read_u32::<BigEndian>。Byteorder 扩展了std::io::Read，以便从字节缓冲区中反序列化原始类型。你可以手动做这件事，但这样做容易出错，而且重复起来很麻烦。使用 byteorder。所以，我们在这里看到的是 hopper 从self.fp——一个指向当前磁盘队列文件的std::io::BufReader——读取 32 位长度的 big-ending 长度前缀，并使用这个前缀从磁盘上读取恰好这么多字节，然后再将这些字节传递给反序列化器。就是这样。所有 hopper 磁盘上的元素都是 32 位长度的前缀，后面跟着这么多字节。

发送者

现在我们已经涵盖了Receiver，剩下的就是Sender。它在src/sender.rs中定义。Sender中最重要的函数是send。Sender遵循与Receiver相同的磁盘/内存模式理念，但在其操作上更为复杂。让我们深入探讨：

        let mut back_guard = self.mem_buffer.lock_back();
        if (*back_guard).inner.total_disk_writes == 0 {
            // in-memory mode
            let placed_event = private::Placement::Memory(event);
            match self.mem_buffer.push_back(placed_event, &mut 
            back_guard) {
                Ok(must_wake_receiver) => {
                    if must_wake_receiver {
                        let front_guard = self.mem_buffer.lock_front();
                        self.mem_buffer.notify_not_empty(&front_guard);
                        drop(front_guard);
                    }
                }
                Err(deque::Error::Full(placed_event)) => {
                    self.write_to_disk(placed_event.extract().unwrap(), 
                    &mut back_guard)?;
                    (*back_guard).inner.total_disk_writes += 1;
                }
            }

回想一下，双端队列允许后端守护者通过它走私状态以进行协调。我们在这里看到了它的回报。Sender的内部状态被称为SenderSync，其定义如下：

pub struct SenderSync {
    pub sender_fp: Option<BufWriter<fs::File>>,
    pub bytes_written: usize,
    pub sender_seq_num: usize,
    pub total_disk_writes: usize,
    pub path: PathBuf, // active fp filename
}

每个发送线程都必须能够写入当前的磁盘队列文件，该文件由 sender_fp 指向。同样，bytes_written 跟踪已经写入磁盘的字节数。Sender 必须跟踪这个值，以便在队列文件变得太大时正确地滚动队列文件。sender_seq_num 定义了当前可写入队列文件的名称，因为它们是从零开始的顺序命名。对我们来说，关键字段是 total_disk_writes。请注意，内存写入——self.mem_buffer.push_back(placed_event, &mut back_guard)——可能会因为 Full 错误而失败。在这种情况下，会调用 self.write_to_disk 将 T 写入磁盘，从而增加磁盘写入的总数。这种写入模式前面有一个检查跨线程 SenderSync，以确定是否有挂起的磁盘写入。记住，在这个时候，Receiver 没有办法确定是否有额外的写入操作已经写入磁盘；与 Receiver 的唯一通信渠道是通过内存中的双端队列。为此，下一个 Sender 线程将切换到不同的写入模式：

        } else {
            // disk mode
            self.write_to_disk(event, &mut back_guard)?;
            (*back_guard).inner.total_disk_writes += 1;
            assert!((*back_guard).inner.sender_fp.is_some());
            if let Some(ref mut fp) = (*back_guard).inner.sender_fp {
                fp.flush().expect("unable to flush");
            } else {
                unreachable!()
            }
            if let Ok(must_wake_receiver) = self.mem_buffer.push_back(
                private::Placement::Disk(
                    (*back_guard).inner.total_disk_writes
                ),
                &mut back_guard,
            ) {
                (*back_guard).inner.total_disk_writes = 0;
                if must_wake_receiver {
                    let front_guard = self.mem_buffer.lock_front();
                    self.mem_buffer.notify_not_empty(&front_guard);
                    drop(front_guard);
                }
            }
        }

一旦有单个写入磁盘，Sender 就切换到磁盘优先写入模式。在这个分支的开始，T 被写入磁盘，并进行刷新。然后，Sender 尝试将一个 Placement::Disk 推送到内存中的双端队列，如果 Receiver 的调度分配缓慢或不走运，可能会失败。然而，如果成功，total_disk_writes 就会被设置为零——不再有任何挂起的磁盘写入，并且如果需要，Receiver 会被唤醒以读取其新的事件。下一次 Sender 线程遍历时，它可能或可能没有足够的空间在内存中的双端队列中执行内存放置，但这将是下一个线程的问题。

这就是 Sender 的核心。虽然模块中还有一个大的函数 write_to_disk，但我们在这里不会列出它。实现主要是使用互斥锁进行账目管理，这个主题在本章和上一章中已经详细讨论过，还包括文件系统操作。话虽如此，我们热情地鼓励好奇的读者阅读代码。

测试并发数据结构

Hopper 是一个微妙的生物，证明要正确地处理它相当棘手，因为要在多个线程之间操作相同的内存很困难。在实现编写过程中，轻微的同步错误很常见，这些错误突出了基本的错误，但很少触发，甚至更难重现。传统的单元测试在这里是不够的。找不到干净的单元，因为计算机的非确定性行为是程序运行最终结果的基本因素。考虑到这一点，hopper 使用了三种关键的测试策略：在随机输入上执行随机测试以寻找逻辑错误（QuickCheck）、在随机输入上执行随机测试以寻找崩溃（模糊测试），以及运行数百万次相同的程序以寻找一致性失败。在接下来的章节中，我们将依次讨论这些策略。

QuickCheck 和循环

前面的章节详细讨论了 QuickCheck，我们在这里不会重复。相反，让我们深入探讨一个来自hopper的测试，该测试在src/lib.rs中定义：

    #[test]
    fn multi_thread_concurrent_snd_and_rcv_round_trip() {
        fn inner(
            total_senders: usize,
            in_memory_bytes: usize,
            disk_bytes: usize,
            max_disk_files: usize,
            vals: Vec<u64>,
        ) -> TestResult {
            let sz = mem::size_of::<u64>();
            if total_senders == 0 || 
               total_senders > 10 || 
               vals.len() == 0 ||
               (vals.len() < total_senders) || 
               (in_memory_bytes / sz) == 0 ||
               (disk_bytes / sz) == 0
            {
                return TestResult::discard();
            }
            TestResult::from_bool(
              multi_thread_concurrent_snd_and_rcv_round_trip_exp(
                total_senders,
                in_memory_bytes,
                disk_bytes,
                max_disk_files,
                vals,
            ))
        }
        QuickCheck::new()
            .quickcheck(inner as fn(usize, usize, usize, usize, 
             Vec<u64>) -> TestResult);
    }

这个测试设置了一个多发送者、单接收者的往返环境，并小心地拒绝那些在内存缓冲区中允许小于 64 位空间、没有发送者或类似情况的输入。它将任务委托给另一个函数multi_thread_concurrent_snd_and_rcv_round_trip_exp来实际运行测试。

这个设置确实有些尴尬，但它的好处是允许multi_thread_concurrent_snd_and_rcv_round_trip_exp在明确的输入上运行。也就是说，当发现错误时，你可以通过创建手动测试或明确地（在 hopper 测试术语中）测试来轻松地重新播放那个测试。内部测试函数很复杂，我们将分部分考虑：

    fn multi_thread_concurrent_snd_and_rcv_round_trip_exp(
        total_senders: usize,
        in_memory_bytes: usize,
        disk_bytes: usize,
        max_disk_files: usize,
        vals: Vec<u64>,
    ) -> bool {
        if let Ok(dir) = tempdir::TempDir::new("hopper") {
            if let Ok((snd, mut rcv)) = 
              channel_with_explicit_capacity(
                "tst",
                dir.path(),
                in_memory_bytes,
                disk_bytes,
                max_disk_files,
            ) {

就像我们在本节开头对 hopper 的示例用法一样，内部测试函数使用 tempdir (crates.io/crates/tempdir)创建一个临时路径，以便传递给channel_with_explicit_capacity。但是，我们在这里非常小心，不要解包。因为 hopper 使用了文件系统，并且因为 Rust QuickCheck 是积极的多线程的，所以任何单个测试运行都可能遇到文件句柄耗尽的情况。这会导致 QuickCheck 出错，测试失败与这次特定执行的输入完全无关。

下一个部分如下：

                let chunk_size = vals.len() / total_senders;

                let mut snd_jh = Vec::new();
                let snd_vals = vals.clone();
                for chunk in snd_vals.chunks(chunk_size) {
                    let mut thr_snd = snd.clone();
                    let chunk = chunk.to_vec();
                    snd_jh.push(thread::spawn(move || {
                        let mut queued = Vec::new();
                        for mut ev in chunk {
                            loop {
                                match thr_snd.send(ev) {
                                    Err(res) => {
                                        ev = res.0;
                                    }
                                    Ok(()) => {
                                        break;
                                    }
                                }
                            }
                            queued.push(ev);
                        }
                        let mut attempts = 0;
                        loop {
                            if thr_snd.flush().is_ok() {
                                break;
                            }
                            thread::sleep(
                              ::std::time::Duration::from_millis(100)
                            );
                            attempts += 1;
                            assert!(attempts < 10);
                        }
                        queued
                    }))
                }

在这里，我们创建了发送者线程，每个线程从vals中抓取一个等大小的块。现在，由于线程调度的不可确定性，我们无法模拟vals元素被推入 hopper 的顺序。我们所能做的就是确认在通过 hopper 传输后没有丢失元素。实际上，它们可能在顺序上被破坏：

                let expected_total_vals = vals.len();
                let rcv_jh = thread::spawn(move || {
                    let mut collected = Vec::new();
                    let mut rcv_iter = rcv.iter();
                    while collected.len() < expected_total_vals {
                        let mut attempts = 0;
                        loop {
                            match rcv_iter.next() {
                                None => {
                                    attempts += 1;
                                    assert!(attempts < 10_000);
                                }
                                Some(res) => {
                                    collected.push(res);
                                    break;
                                }
                            }
                        }
                    }
                    collected
                });

                let mut snd_vals: Vec<u64> = Vec::new();
                for jh in snd_jh {
                    snd_vals.append(&mut jh.join().expect("snd join 
                    failed"));
                }
                let mut rcv_vals = rcv_jh.join().expect("rcv join 
                failed");

                rcv_vals.sort();
                snd_vals.sort();

                assert_eq!(rcv_vals, snd_vals);

另一个只有一个发送者的测试single_sender_single_rcv_round_trip能够检查正确的顺序以及没有数据丢失：

    #[test]
    fn single_sender_single_rcv_round_trip() {
        // Similar to the multi sender test except now with a single 
        // sender we can guarantee order.
        fn inner(
            in_memory_bytes: usize,
            disk_bytes: usize,
            max_disk_files: usize,
            total_vals: usize,
        ) -> TestResult {
            let sz = mem::size_of::<u64>();
            if total_vals == 0 || (in_memory_bytes / sz) == 0 || 
            (disk_bytes / sz) == 0 {
                return TestResult::discard();
            }
            TestResult::from_bool(
              single_sender_single_rcv_round_trip_exp(
                in_memory_bytes,
                disk_bytes,
                max_disk_files,
                total_vals,
            ))
        }
        QuickCheck::new().quickcheck(inner as fn(usize, usize, 
                                     usize, usize) -> TestResult);
    }

就像它的多堂兄弟一样，这个 QuickCheck 测试使用一个内部函数来执行实际的测试：

    fn single_sender_single_rcv_round_trip_exp(
        in_memory_bytes: usize,
        disk_bytes: usize,
        max_disk_files: usize,
        total_vals: usize,
    ) -> bool {
        if let Ok(dir) = tempdir::TempDir::new("hopper") {
            if let Ok((mut snd, mut rcv)) = 
            channel_with_explicit_capacity(
                "tst",
                dir.path(),
                in_memory_bytes,
                disk_bytes,
                max_disk_files,
            ) {
                let builder = thread::Builder::new();
                if let Ok(snd_jh) = builder.spawn(move || {
                    for i in 0..total_vals {
                        loop {
                            if snd.send(i).is_ok() {
                                break;
                            }
                        }
                    }
                    let mut attempts = 0;
                    loop {
                        if snd.flush().is_ok() {
                            break;
                        }
                        thread::sleep(
                          ::std::time::Duration::from_millis(100)
                        );
                        attempts += 1;
                        assert!(attempts < 10);
                    }
                }) {
                    let builder = thread::Builder::new();
                    if let Ok(rcv_jh) = builder.spawn(move || {
                        let mut rcv_iter = rcv.iter();
                        let mut cur = 0;
                        while cur != total_vals {
                            let mut attempts = 0;
                            loop {
                                if let Some(rcvd) = rcv_iter.next() {
                                    debug_assert_eq!(
                                        cur, rcvd,
                                    "FAILED TO GET ALL IN ORDER: {:?}",
                                        rcvd,
                                    );
                                    cur += 1;
                                    break;
                                } else {
                                    attempts += 1;
                                    assert!(attempts < 10_000);
                                }
                            }
                        }
                    }) {
                        snd_jh.join().expect("snd join failed");
                        rcv_jh.join().expect("rcv join failed");
                    }
                }
            }
        }
        true
    }

这一点也应该很熟悉，只是现在接收线程能够检查顺序。之前是将Vec<u64>输入到函数中，我们现在通过跳转队列流式传输0, 1, 2, .. total_vals，断言顺序并且另一侧没有间隙。对单个输入的单次运行将无法可靠地触发低概率竞态问题，但这不是目标。我们正在寻找逻辑错误。例如，这个库的早期版本会愉快地允许内存中的最大字节数小于元素T的总字节数。另一个版本可以将多个T实例放入缓冲区，但如果total_vals是奇数并且内存大小足够小以至于需要磁盘分页，那么流中的最后一个元素将永远不会被踢出。实际上，这仍然是一个问题。这是发送者中懒惰翻转至磁盘模式的结果；如果没有其他元素可能触发磁盘放置到内存缓冲区，写入将被刷新到磁盘，但接收者永远不会意识到这一点。为此，发送者确实提供了一个flush函数，您可以在测试中看到它的使用。在实践中，在 cernan 中，刷新是不必要的。但是，这是设计者没有预料到的设计角落，如果这个设计被广泛使用，可能很难注意到这个问题。

我们单发送者变体的内部测试也用于跳转测试的重复循环变体：

    #[test]
    fn explicit_single_sender_single_rcv_round_trip() {
        let mut loops = 0;
        loop {
         assert!(single_sender_single_rcv_round_trip_exp(8, 8, 5, 10));
            loops += 1;
            if loops > 2_500 {
                break;
            }
            thread::sleep(::std::time::Duration::from_millis(1));
        }
    }

注意，这里的内部循环仅进行 2,500 次迭代。这是为了尊重 CI 服务器的需求，它们不介意连续几小时运行高 CPU 负载的代码。在开发过程中，这个 2,500 次将会调整增加。但核心思想是明显的；检查一系列有序输入是否能够一次又一次地通过跳转队列按顺序且完整地返回。QuickCheck 搜索状态空间中的暗角，而更传统的手动测试则反复敲打同一位置以挖掘计算机的不确定性。

使用 AFL 搜索崩溃

上一节中测试的重复循环变体很有趣。它不像 QuickCheck 那样，完全专注于寻找逻辑错误。我们知道测试将在大多数迭代中工作。在那里寻找的是未能正确控制底层机器的不确定性。在某种程度上，这种测试变体使用逻辑检查来搜索崩溃。它是一种模糊测试。

Hopper 与文件系统交互，创建线程，并从文件中操作字节。这些活动都可能因为资源不足、偏移错误或对介质的基本误解而失败。例如，hopper 的早期版本假设对磁盘的小原子写入不会交错，这在 XFS 中是正确的，但在大多数其他文件系统中则不正确。或者，hopper 的另一个版本总是通过更熟悉的 thread::spawn 来创建测试中的线程。然而，如果无法创建线程，这个函数会引发恐慌，这就是为什么测试使用 thread::Builder 模式而不是，允许恢复。

崩溃本身很重要。为此，hopper 有一个基于 AFL 的模糊设置。为了避免在用户系统上产生不必要的二进制文件，截至本文撰写时，hopper 项目没有托管自己的模糊代码。相反，它位于 blt/hopper-fuzz (github.com/blt/hopper-fuzz)。诚然，这很尴尬，但模糊测试，由于其不常见，通常是这样的。模糊测试可能持续数天，而且不适合现代 CI 系统。AFL 本身也不是一个容易自动化的工具，这也加剧了问题。模糊测试通常在用户私有机器上的小批量中进行，至少对于社区规模较小的开源项目是这样的。在 hopper-fuzz 中，有一个用于模糊测试的单个程序，其前言如下：

extern crate hopper;
extern crate rand;
#[macro_use]
extern crate serde_derive;
extern crate bincode;
extern crate tempdir;

use bincode::{deserialize_from, Bounded};
use self::hopper::channel_with_explicit_capacity;
use std::{io, process};
use rand::{Rng, SeedableRng, XorShiftRng};

基于我们迄今为止所看到的，相当直接。将输入传递给模糊程序有时并不简单，尤其是当输入不仅仅是输入集而不是，比如说，解析器的情况下的程序的实际工作单元。作者的方法是依赖 serde 来反序列化 AFL 将投入程序的字节缓冲区，知道大多数有效载荷将无法解码，但并不太在意。为此，作者模糊程序的顶部通常有一个填充了控制数据的输入结构体，这个程序也不例外：

#[derive(Debug, PartialEq, Deserialize)]
struct Input { // 22 bytes
    seed_a: u32, // 4
    seed_b: u32, // 4
    seed_c: u32, // 4
    seed_d: u32, // 4
    max_in_memory_bytes: u32, // 4
    max_disk_bytes: u16, // 2
}

种子是为 XorShiftRng，而 max_in_memory_bytes 和 max_disk_bytes 是为 hopper。仔细计算输入的字节大小，以避免模糊测试 bincode 反序列化器拒绝异常大输入的能力。虽然 AFL 不是盲目的——毕竟它已经对程序的分支进行了仪器化——但它也不是很聪明。完全有可能，程序员想要模糊测试的内容并不是一开始就模糊测试的内容。在模糊项目中引入任何额外的库中找出错误并不罕见。这是为了将库的使用限制在最小范围内，并使其使用最小化。

模糊程序的 main 函数开始于与其他 hopper 测试类似的设置：

fn main() {
    let stdin = io::stdin();
    let mut stdin = stdin.lock();
    if let Ok(input) = deserialize_from(&mut stdin, Bounded(22)) {
        let mut input: Input = input;
        let mut rng: XorShiftRng =
            SeedableRng::from_seed([input.seed_a, input.seed_b, 
                                    input.seed_c, input.seed_d]);

        input.max_in_memory_bytes = 
          if input.max_in_memory_bytes > 2 << 25 {
            2 << 25
        } else {
            input.max_in_memory_bytes
        };

        // We need to be absolutely sure we don't run into another 
        // running process. Which, this isn't a guarantee but 
        // it's _pretty_ unlikely to hit jackpot.
        let prefix = format!(
            "hopper-{}-{}-{}",
            rng.gen::<u64>(),
            rng.gen::<u64>(),
            rng.gen::<u64>()
        );

唯一奇怪的是前缀的产生。与 AFL 将要运行的数以百万计的测试相比，tempdir名称中的熵相对较低。我们特别想要确保没有两个料斗运行具有相同的数据目录，因为这将是未定义的行为：

        if let Ok(dir) = tempdir::TempDir::new(&prefix) {
            if let Ok((mut snd, mut rcv)) = 
            channel_with_explicit_capacity(
                "afl",
                dir.path(),
                input.max_in_memory_bytes as usize,
                input.max_disk_bytes as usize,
            ) {

AFL 测试的核心内容令人惊讶：

                let mut writes = 0;
                let mut rcv_iter = rcv.iter();
                loop {
                    match rng.gen_range(0, 102) {
                        0...50 => {
                            if writes != 0 {
                                let _ = rcv_iter.next();
                            }
                        }
                        50...100 => {
                            snd.send(rng.gen::<u64>());
                            writes += 1;
                        }
                        _ => {
                            process::exit(0);
                        }
                    }
                }
            }
        }
    }
}

这个程序引入了一个随机数生成器，在执行读取和写入料斗通道操作之间进行切换。为什么没有使用线程？好吧，结果是，AFL 在模型中很难适应线程。AFL 有一个稳定性概念，即它能够重新运行一个程序，并在指令执行等方面达到相同的结果。在多线程使用料斗的情况下，这行不通。尽管如此，尽管错过了探测发送者和接收者线程之间潜在竞争条件的机会，这个模糊测试发现：

• 文件描述符耗尽导致的崩溃

• 双端队列中的错误偏移计算

• 发送者/接收者级别的错误偏移计算

• 将元素反序列化到未清除的缓冲区中，导致产生幽灵元素

• 算术溢出/下溢导致的崩溃

• 分配足够空间进行序列化失败。

仅在多线程环境中发生的内部双端队列问题将会被忽略，当然，但前面的列表并非微不足道。

基准测试

好吧，到目前为止，我们可以合理地确信料斗适合使用，至少在不会崩溃并产生正确结果方面。但是，它也需要快速。为此，料斗附带 criterion（crates.io/crates/criterion）基准测试。截至写作时，criterion 是一个快速发展的库，它对基准运行结果进行统计分析，而 Rust 内置的夜间基准测试库则没有。此外，criterion 还可在稳定渠道上使用。要匹配的目标是标准库的 MPSC，这为料斗设定了基线。为此，基准测试套件执行了比较，位于料斗存储库中的benches/stdlib_comparison.rs。

前置代码很典型：

#[macro_use]
extern crate criterion;
extern crate hopper;
extern crate tempdir;

use std::{mem, thread};
use criterion::{Bencher, Criterion};
use hopper::channel_with_explicit_capacity;
use std::sync::mpsc::channel;

注意，我们已经引入了 MPSC 和料斗。我们将要基准测试的 MPSC 函数是：

fn mpsc_tst(input: MpscInput) -> () {
    let (tx, rx) = channel();

    let chunk_size = input.ith / input.total_senders;

    let mut snd_jh = Vec::new();
    for _ in 0..input.total_senders {
        let tx = tx.clone();
        let builder = thread::Builder::new();
        if let Ok(handler) = builder.spawn(move || {
            for i in 0..chunk_size {
                tx.send(i).unwrap();
            }
        }) {
            snd_jh.push(handler);
        }
    }

    let total_senders = snd_jh.len();
    let builder = thread::Builder::new();
    match builder.spawn(move || {
        let mut collected = 0;
        while collected < (chunk_size * total_senders) {
            let _ = rx.recv().unwrap();
            collected += 1;
        }
    }) {
        Ok(rcv_jh) => {
            for jh in snd_jh {
                jh.join().expect("snd join failed");
            }
            rcv_jh.join().expect("rcv join failed");
        }
        _ => {
            return;
        }
    }
}

一些发送线程被创建，一个接收者存在，并尽可能快地从 MPSC 中提取值。这根本不是逻辑检查，收集到的材料立即被丢弃。就像模糊测试一样，函数的输入是结构化数据。MpscInput定义如下：

#[derive(Debug, Clone, Copy)]
struct MpscInput {
    total_senders: usize,
    ith: usize,
}

这个函数的料斗版本稍微长一些，因为需要处理更多的错误状态，但我们之前都见过：

fn hopper_tst(input: HopperInput) -> () {
    let sz = mem::size_of::<u64>();
    let in_memory_bytes = sz * input.in_memory_total;
    let max_disk_bytes = sz * input.max_disk_total;
    if let Ok(dir) = tempdir::TempDir::new("hopper") {
        if let Ok((snd, mut rcv)) = channel_with_explicit_capacity(
            "tst",
            dir.path(),
            in_memory_bytes,
            max_disk_bytes,
            usize::max_value(),
        ) {
            let chunk_size = input.ith / input.total_senders;

            let mut snd_jh = Vec::new();
            for _ in 0..input.total_senders {
                let mut thr_snd = snd.clone();
                let builder = thread::Builder::new();
                if let Ok(handler) = builder.spawn(move || {
                    for i in 0..chunk_size {
                        let _ = thr_snd.send(i);
                    }
                }) {
                    snd_jh.push(handler);
                }
            }

            let total_senders = snd_jh.len();
            let builder = thread::Builder::new();
            match builder.spawn(move || {
                let mut collected = 0;
                let mut rcv_iter = rcv.iter();
                while collected < (chunk_size * total_senders) {
                    if rcv_iter.next().is_some() {
                        collected += 1;
                    }
                }
            }) {
                Ok(rcv_jh) => {
                    for jh in snd_jh {
                        jh.join().expect("snd join failed");
                    }
                    rcv_jh.join().expect("rcv join failed");
                }
                _ => {
                    return;
                }
            }
        }
    }
}

同样适用于HopperInput：

#[derive(Debug, Clone, Copy)]
struct HopperInput {
    in_memory_total: usize,
    max_disk_total: usize,
    total_senders: usize,
    ith: usize,
}

Criterion 提供了许多运行基准测试的选项，但在这里我们选择在输入上运行。以下是 MPSC 的设置：

fn mpsc_benchmark(c: &mut Criterion) {
    c.bench_function_over_inputs(
        "mpsc_tst",
        |b: &mut Bencher, input: &MpscInput| b.iter(|| 
         mpsc_tst(*input)),
        vec![
            MpscInput {
                total_senders: 2 << 1,
                ith: 2 << 12,
            },
        ],
    );
}

为了解释，我们有一个函数，mpsc_benchmark，它接受可变的 criterion 结构，这个结构在使用时是透明的，但其中 criterion 会存储运行数据。这个结构暴露了bench_function_over_inputs，它消耗一个闭包，我们可以通过mpsc_test来传递。唯一的输入列在一个向量中。以下是一个设置，它做的是同样的事情，但针对 hopper：

fn hopper_benchmark(c: &mut Criterion) {
    c.bench_function_over_inputs(
        "hopper_tst",
        |b: &mut Bencher, input: &HopperInput| b.iter(|| 
         hopper_tst(*input)),
        vec![
            // all in-memory
            HopperInput {
                in_memory_total: 2 << 11,
                max_disk_total: 2 << 14,
                total_senders: 2 << 1,
                ith: 2 << 11,
            },
            // swap to disk
            HopperInput {
                in_memory_total: 2 << 11,
                max_disk_total: 2 << 14,
                total_senders: 2 << 1,
                ith: 2 << 12,
            },
        ],
    );
}

注意现在我们有两个输入，一个是保证全部在内存中，另一个保证需要磁盘分页。磁盘分页输入的大小适当，以匹配 MSPC 运行。对于 hopper 和 MPSC 进行内存比较并无害处，但作者更倾向于悲观的基准测试，因为作者是一个乐观主义者。以下是我们将在本书剩余部分看到的基准测试中需要的最终位几乎都是稳定的：

criterion_group!{
    name = benches;
    config = Criterion::default().without_plots();
    targets = hopper_benchmark, mpsc_benchmark
}
criterion_main!(benches);

我鼓励你自己运行基准测试。我们看到 hopper 的时间大约是我们打算为 hopper 设计的系统的三倍快。这已经足够快了。

摘要

在本章中，我们介绍了剩余的基本非原子 Rust 同步原语，对 postmates/hopper 库进行了深入研究，以探索其在生产代码库中的应用。在消化了第四章，同步与发送 – Rust 并发的基石，以及本章内容后，读者应该能够很好地在 Rust 中构建基于锁的并发数据结构。对于需要更高性能的读者，我们将在第六章，原子操作 – 同步的原始操作，和第七章，原子操作 – 安全地回收内存中探讨原子编程主题。

如果你认为基于锁的并发很困难，那么等你看到原子操作。

进一步阅读

构建并发数据结构是一个广泛关注的领域。这些笔记涵盖了与第四章，同步与发送 – Rust 并发的基石中笔记几乎相同的空间。请务必参考那些笔记。

• 《信号量小书》，艾伦·道尼，可在greenteapress.com/wp/semaphores/找到。这是一本关于并发谜题的迷人书籍，适合本科生阅读，但在 Rust 中由于没有信号量，挑战性也足够大。我们将在下一章构建原子并发原语时再次回顾这本书。

• *《松散数据结构的可计算性：队列和栈为例》，作者：尼尔·沙维特和加迪·塔本菲尔德。本章讨论了基于《多处理器编程的艺术》的演示和作者对 Erlang 进程队列的了解实现的并发队列。队列是一种常见的并发数据结构，有许多可能的实现方法。本文讨论了一个有趣的概念。也就是说，如果我们放松队列的排序约束，我们能否从现代机器中挤出更多的性能？

• 《并行编程难吗？如果难，你能做什么？》，作者：保罗·麦肯尼。这本书涵盖了与第四章，同步与发送——Rust 并发的基础和第五章，锁——互斥锁、条件变量、屏障和读写锁大致相同的材料，但内容更为详细。我强烈建议读者寻找这本书的副本并阅读它，尤其是关于验证实现的第十一章。

第六章：原子 – 同步的原始元素

在第四章，Sync 和 Send – Rust 并发的基石，以及第五章，锁 – Mutex、Condvar、屏障和 RWLock中，我们讨论了 Rust 中基于锁的并发基础。然而，在某些情况下，基于锁的编程并不适用，例如当极端性能是关注点或线程可能永远不会阻塞时。在这些领域，程序员必须依赖现代 CPU 的原子同步原语。

在本章中，我们将讨论 Rust 程序员可用的原子原语。使用原子编程是一个复杂的话题，也是一个活跃的研究领域。整本书都可以专门讨论原子 Rust 编程。因此，我们将为本章稍微调整策略，更多地采用教程风格，而不是之前章节中对现有软件的深入研究。前几章中介绍的所有内容都将在此处得到应用。到本章结束时，你应该对原子有实际的理解，能够更容易地消化现有文献，并验证你的实现。

到本章结束时，我们将：

• 讨论了可线性化性的概念

• 讨论各种原子内存排序，以及它们的含义和影响

• 从原子原语构建互斥锁

• 从原子原语构建队列

• 从原子原语构建信号量

• 清晰地阐述了在原子上下文中内存回收的困难

技术要求

本章需要安装一个可工作的 Rust 环境。验证安装的详细信息请参阅第一章，预备知识 – 计算机架构和 Rust 入门。不需要额外的软件工具。

您可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。本章的源代码位于Chapter06。

可线性化性

到目前为止，本书在指定并发系统时，一直避免使用正式术语，因为虽然它们在讨论思想和推理时非常有用，但如果没有一些背景知识，它们可能很难学习。现在我们已经有了背景知识，是时候了。

我们如何决定一个并发算法是否正确？如果我们对算法感兴趣，我们如何分析实现并推理其正确性？到目前为止，我们使用技术通过随机和重复测试以及模拟（在 helgrind 的情况下）来证明实现的适用性。我们将继续这样做。实际上，如果我们只是这样做，证明实现的适用性，那么我们会处于相当好的状态。工作的程序员会发现他们经常在发明，将算法改编以适应某些新颖的领域——正如前一章关于 hopper 的讨论中所见。这样做很容易，而且往往不会注意到。

当我们坐下来推理我们所构建的系统时，我们正在寻找的是一个统一的概念，这个概念能够将可行的想法与错误区分开来。对我们来说，在这里，在设计并发数据结构时，这个概念就是线性化。我们想要构建的对象，用 Nancy Lynch 的话来说，使得对这些对象的操作似乎是一次一个，按照某种顺序发生，与操作的顺序和响应一致。Lynch 的《分布式算法》关注分布式系统的行为，但我一直认为她对所谓的原子对象的解释非常简洁而精辟。

线性化的概念是在 1986 年 Herlihy 和 Wing 的《并发对象的公理》一文中提出的。他们的定义稍微复杂一些，涉及到历史——一系列操作调用和响应事件**——以及规范，简而言之，就是一组关于对象上定义的操作的公理前条件和后条件。

让操作的成果称为 res(op)，操作的调用或应用称为 inv(op)，并通过一些额外的标识符来区分操作。op_1 与 op_2 不同，但标识符不影响它们的排序；它只是一个名字。历史 H 是操作上的一个偏序，使得 op_0 < op_1 如果在 H 中 res(op_0) 发生在 inv(op_1) 之前。在 < 没有排序关系的操作在历史中是并发的。如果历史 H 中所有操作都按照 < 排序，则 H 是顺序的。现在，如果历史 H 可以通过添加零个或多个操作进行调整，使得另一个历史 H' 如下，则 H 是可线性化的：

1. H' 只包含调用和响应，并且与某个合法的顺序历史 S 等价。

2. H' 的排序操作是 S 排序的包含子集。

哇！如果一个对象的操作顺序可以被记录下来，对其进行一些调整，并找到一个等效的同一对象上的操作序列应用，那么这个对象就是可线性化的。我们实际上在之前的章节中已经进行了线性化分析，只是我没有将其称为此类。让我们继续跟随 Herlihy 和 Wing，看看他们关于可线性化与不可线性化历史记录的例子。以下是一个熟悉的队列的历史记录：

A: Enq(x)       0
B: Enq(y)       1
B: Ok(())       2
A: Ok(())       3
B: Deq()        4
B: Ok(x)        5
A: Deq()        6
A: Ok(y)        7
A: Enq(z)       8

我们有两个线程，A和B，执行操作enq(val: T) -> Result((), Error)和deq() -> Result(T, Error)，以伪 Rust 类型表示。这个历史记录实际上是可线性化的，并且与以下等效：

A: Enq(x)       0
A: Ok(())       3
B: Enq(y)       1
B: Ok(())       2
B: Deq()        4
B: Ok(x)        5
A: Deq()        6
A: Ok(y)        7
A: Enq(z)       8
A: Ok(())

注意，在原始历史记录中最后一步操作并不存在。正如 Herlihy 和 Wing 所指出的，即使一个操作在其响应之前生效，历史记录仍然可能是可线性化的。例如：

A: Enq(x)       0
B: Deq()        1
C: Ok(x)        2

这与以下顺序历史记录等效：

A: Enq(x)       0
A: Ok(())
B: Deq()        1
B: Ok(x)        2

这个历史记录是不可线性化的：

A: Enq(x)       0
A: Ok(())       1
B: Enq(y)       2
B: Ok(())       3
A: Deq()        4
A: Ok(y)        5

在这种情况下，罪魁祸首是队列排序的违反。在顺序历史记录中，出队操作将接收x而不是y。

就这些了。当我们谈论一个结构是可线性化的时，我们真正询问的是，针对该结构的任何有效操作列表是否可以被重新排序或添加，以至于列表与顺序历史记录无法区分？我们在上一章中查看的每个同步工具都被用来通过仔细排序线程间操作的顺序来强制线性化。在另一个层面上，这些工具也操纵了内存加载和存储的顺序。直接控制这种顺序，同时控制结构上操作的顺序，将占据本章的剩余部分。

内存排序——happens-before 和 synchronizes-with

每个 CPU 架构对内存排序——加载和存储之间的依赖关系——的处理方式不同。我们已经在第一章中详细讨论了这一点，预备知识 – 机器架构和 Rust 入门。在此简要说明，x86 是一个强排序架构；某些线程的存储操作将按执行顺序被所有其他线程看到。与此同时，ARM 是一个具有数据依赖性的弱排序架构；加载和存储可以以任何方式重新排序，除了那些会违反单个、孤立线程的行为之外，并且，如果一个加载依赖于之前加载的结果，你可以保证之前的加载将发生而不是被缓存。Rust 向程序员暴露了自己的内存排序模型，抽象掉了这些细节。因此，我们的程序必须根据 Rust 的模型正确，我们必须信任rustc能够正确地为我们目标 CPU 解释这些。如果我们破坏了 Rust 的模型，我们可能会看到rustc重新排序指令以破坏线性化，即使我们的目标 CPU 的保证原本可以帮助我们顺利通过。

我们在第三章“Rust 内存模型 – 所有权、引用和操作”中详细讨论了 Rust 的内存模型，指出其底层细节几乎完全继承自 LLVM（以及因此的 C/C++）。然而，我们推迟了对模型中依赖关系的讨论，直到本章。这个话题本身就足够复杂，您将直接看到这一点。由于这样做存在重大困难，我们不会在这里深入细节；请参阅 LLVM 的并发操作的内存模型(llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations)及其链接树，以获得全面且具有挑战性的阅读材料。相反，我们将指出，除了编写优化器或特别具有挑战性的需要研究 LLVM 内存模型引用的低级代码之外，理解当我们在 Rust 中谈论排序时，我们谈论的是一种特定的因果关系——发生之前/同步于就足够了。只要我们根据这种因果关系来结构我们的操作，并能证明线性化，我们就会处于良好的状态。

发生之前/同步于因果关系是什么？这些中的每一个都指代一种特定的排序关系。假设我们有三个操作A、B和C。我们说A 发生之前 B，如果：

• A和B在同一线程上执行，并且A根据程序顺序先执行，然后B执行

• A发生之前C，且C发生之前B

• A 同步于 B

注意，第一个点指的是单线程程序顺序。Rust 不保证多线程程序顺序，但确实断言单线程代码将按照其明显的文本顺序运行，即使实际上优化的 Rust 被重新排序，底层硬件也在重新排序。如果我们说A 同步于 B，如果以下所有条件都成立：

• B是从某个具有Acquire或SeqCst排序的原子变量var中加载

• A是将具有Release或SeqCst排序的值存储到相同的原子变量var中

• B从var读取值

最后一点存在是为了确保编译器或硬件不会优化掉第一点中的加载。但是，是否有一些额外的信息卡在了那里？是的！稍后我们将详细介绍。

线性化是如何与我们所描述的因果排序联系起来的？理解这一点非常重要。在 Rust 中，一个结构可以遵循因果排序，但在检查时仍然不能线性化。以之前章节中关于环形结构的讨论为例，尽管因果排序被互斥锁保护，但由于偏移量错误，写入被覆盖。那个实现不是可线性化的，但它是有因果排序的。从这个意义上说，那么，获取你程序的因果性是编写适合用途的并发数据结构的必要条件，但不是充分条件。线性化是针对结构上的操作进行的分析，而 happens-before/synchronizes-with 是一种在操作内部和操作之间发生的排序。

现在，我们提到了Acquire、SeqCst和Release；它们是什么？Rust 的内存排序模型允许对加载和存储应用不同的原子排序。这些排序控制着底层 CPU 和rustc优化器的指令调度，以及何时使流水线等待加载的结果。这些排序在名为std::sync::atomic::Ordering的枚举中定义。我们将逐一介绍它们。

Ordering::Relaxed

这种排序并没有出现在“happens-before/synchronizes-with”的定义中。这有一个非常好的原因。Relaxed排序意味着没有保证。带有Relaxed排序的加载和存储可以自由地围绕一个加载或存储进行重新排序。也就是说，加载和存储可以从Relaxed操作的角度在程序顺序中向上或向下迁移。

编译器和硬件在Relaxed排序出现时可以随意操作。正如我们将在接下来的详细示例中看到的那样，这有很多实用价值。现在，考虑一下用于自我遥测的并发程序中的计数器，或者设计为最终一致性的数据结构。那里不需要严格的排序。

在我们继续之前，值得非常清楚地说明我们所说的加载和存储的排序是什么意思。加载和存储在什么上？嗯，原子操作。在 Rust 中，这些在std::sync::atomic中公开，截至撰写本书时，有四种稳定的原子类型可用：

• AtomicUsize

• AtomicIsize

• AtomicPtr

• AtomicBool

目前有一个围绕使用 Rust 问题#32976来支持更小的原子类型进行的讨论——你会注意到，在稳定的四种类型中，三种是机器字大小，而AtomicBool目前也是其中之一——但那里的进展似乎已经停滞，因为没有找到合适的领导者。所以，现在这些是类型。当然，除了原子操作之外，还有更多的负载和存储——以原始指针的操作为例。这些是数据访问，并且没有比 Rust 一开始内置的更多的排序保证。两个线程可能在同一时刻对相同的原始指针进行负载和存储，而且如果没有事先协调，对此无能为力。

Ordering::Acquire

Acquire是一种处理负载的排序。回想一下，我们之前说过，如果一个线程B以Acquire排序加载变量，而线程A随后以Release排序存储，那么A与B同步，这意味着A发生在B之前。回想一下，在前一章中，我们在 hopper 的上下文中遇到了Acquire：

    pub unsafe fn push_back(
        &self,
        elem: T,
        guard: &mut MutexGuard<BackGuardInner<S>>,
    ) -> Result<bool, Error<T>> {
        let mut must_wake_dequeuers = false;
        if self.size.load(Ordering::Acquire) == self.capacity {
            return Err(Error::Full(elem));
        } else {
            assert!((*self.data.offset((*guard).offset)).is_none());
            *self.data.offset((*guard).offset) = Some(elem);
            (*guard).offset += 1;
            (*guard).offset %= self.capacity as isize;
            if self.size.fetch_add(1, Ordering::Release) == 0 {
                must_wake_dequeuers = true;
            }
        }
        Ok(must_wake_dequeuers)
    }

那里的大小是一个AtomicUsize，当前线程正在使用它来确定是否有空间放置新元素。一旦元素被放置，线程将使用Release排序来增加大小。这……似乎很荒谬。显然，增加大小的程序顺序在容量检查之前发生是不直观的。而且，这是真的。值得记住的是，游戏中还有另一个线程：

    pub unsafe fn pop_front(&self) -> T {
        let mut guard = self.front_lock.lock()
                          .expect("front lock poisoned");
        while self.size.load(Ordering::Acquire) == 0 {
            guard = self.not_empty
                .wait(guard)
                .expect("oops could not wait pop_front");
        }
        let elem: Option<T> = mem::replace(&mut 
        *self.data.offset((*guard).offset), None);
        assert!(elem.is_some());
        *self.data.offset((*guard).offset) = None;
        (*guard).offset += 1;
        (*guard).offset %= self.capacity as isize;
        self.size.fetch_sub(1, Ordering::Release);
        elem.unwrap()
    }

考虑如果只有两个线程A和B，A只执行push_back操作，而B只执行pop_front操作会发生什么。mutexes函数用于为相同类型的线程提供隔离——那些执行推或弹操作的线程——因此在这个假设中是无关紧要的，可以忽略。所有重要的是原子操作。如果大小为零，并且B首先被调度，它将在大小为Acquire负载的condvar循环中清空。当A被调度并发现其元素有额外的容量时，该元素将被排队，一旦完成，大小将被Release存储，这意味着B中某个幸运的循环将在A成功执行push_back操作之后发生。

Rust 文档中关于Acquire的说明是：

"当与负载结合时，所有后续的负载都将看到在具有释放排序的其他线程中相同值的存储之前写入的数据。"

LLVM 文档说明：

"Acquire 提供了一种必要的屏障，以获取锁来使用正常负载和存储访问其他内存。"

我们应该如何理解这一点？Acquire负载阻止在其之后的负载和存储迁移到更高的程序顺序。然而，在Acquire之前的负载和存储可能会迁移到更低的程序顺序。将Acquire视为类似于锁的起点，但顶部是渗透的。

Ordering::Release

如果 Acquire 是锁的起点，那么 Release 就是终点。实际上，LLVM 文档中提到：

"Release 与 Acquire 类似，但需要一个释放锁的屏障。"

这可能比 lock 可能暗示的要微妙一些。以下是 Rust 文档中的说明：

"当与存储结合时，所有之前的写入对执行 Acquire 排序的同一值的加载的其他线程都变得可见。"

在 Acquire 停止其后的加载和存储向上迁移时，Release 停止其之前的加载和存储向下迁移，关于程序顺序。就像 Acquire 一样，Release 不会阻止其之前的加载和存储向上迁移。一个 Release 存储类似于锁的终点，但底部是渗透性的。

顺便说一下，这里有一个有趣的复杂情况，锁的直觉在这里并不适用。问题：两个 Acquire 加载或两个 Release 存储可以同时发生吗？答案是，嗯，这取决于很多因素，但这是可能的。在先前的 hopper 示例中，自旋的 pop_front 线程并不会阻止 push_back 线程执行其大小检查，即使是通过永久持有大小直到 Release 来释放 pop_front 线程，即使只是临时地，直到 while 循环可以被检查。记住，语言的因果关系模型对两个 Acquire 加载或 Release 存储的排序一无所知。发生什么是不确定的，并且可能强烈依赖于你的硬件。我们所知道的是，pop_front 线程将不会部分地看到 push_back 对内存所做的存储；它将是全部或无的。在 Acquire 和 Release 之后的加载和存储作为一个单元出现。

Ordering::AcqRel

这个变体是 Acquire 和 Release 的组合。当一个加载操作使用 AcqRel 执行时，就会使用 Acquire 并将其存储到 Release。AcqRel 不仅是一个便利的组合，它结合了 Acquire 和 Release 的排序行为——两边的排序都是渗透性的。也就是说，在 AcqRel 之后，加载和存储不能向上移动，就像 Acquire 一样，而在 AcqRel 之前的加载和存储也不能向下移动，就像 Release 一样。这是一个巧妙的技巧。

在继续到下一个排序变体之前，值得指出的是，到目前为止，我们只看到了线程以成对的方式执行 Acquire/Release 的示例，与另一个线程合作。这不必是这样。一个线程始终可以执行 Acquire，另一个线程始终可以执行 Release。因果关系定义是专门针对执行一个但不是两个的线程，当然，除非 A 等于 B。让我们分析一个例子：

A: store X                   1
A: store[Release] Y          2
B: load[Acquire] Y           3
B: load X                    4
B: store[Release] Z          5
C: load[Acquire] Z           6
C: load X                    7

在这里，我们有三个线程A、B和C，它们执行了一系列的普通加载和存储操作，以及原子加载和存储操作。store[Release]是一个原子存储操作，而存储不是。正如线性可化性部分所讨论的，我们给每个操作都编了号，但请注意，这并不代表时间线，因为数字只是方便的名称。我们能说这个例子中的因果关系是什么吗？我们知道：

• 1 happens-before 2

• 2 synchronizes-with 3

• 3 happens-before 4

• 3 happens-before 5

• 5 synchronizes-with 6

• 6 happens-before 7

我们将在本章后面看到更多此类分析。

Ordering::SeqCst

最后，在Relaxed的对立面，存在SeqCst，代表 SEQuentially ConsiSTent（顺序一致）。SeqCst类似于AcqRel，但额外的好处是，在顺序一致的操作之间，所有线程之间都有一个总顺序，因此得名。SeqCst是一个相当严肃的同步原语，你只有在极有必要的情况下才应该使用它，因为强制所有线程之间的总顺序并不便宜；每个原子操作都将需要一个同步周期，无论这对你的 CPU 意味着什么。例如，互斥锁（mutex）是一个获取-释放结构——稍后我们会详细讨论这一点——但确实存在使用类似SeqCst这样的超级互斥锁的合理情况。例如，实现旧论文。在原子编程的早期，更宽松——但不是Relaxed——的内存顺序的确切后果并没有完全理解。你会看到一些文献会使用顺序一致的内存，但对此并不在意。至少，跟随并按需放松。这种情况可能比你想象的要多，至少对你的作者来说是这样。你的体验可能会有所不同。有些情况下，我们似乎陷入了SeqCst的困境。考虑一个多生产者、多消费者设置，如下所示，这是从 CppReference 中改编的（参见最后部分显示的 进一步阅读 部分）：

#[macro_use]
extern crate lazy_static;

use std::thread;
use std::sync::Arc;
use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering};

lazy_static! {
static ref X: Arc<AtomicBool> = Arc::new(AtomicBool::new(false));
static ref Y: Arc<AtomicBool> = Arc::new(AtomicBool::new(false));
static ref Z: Arc<AtomicUsize> = Arc::new(AtomicUsize::new(0));
}

fn write_x() {
    X.store(true, Ordering::SeqCst);
}

fn write_y() {
    Y.store(true, Ordering::SeqCst);
}

fn read_x_then_y() {
    while !X.load(Ordering::SeqCst) {}
    if Y.load(Ordering::SeqCst) {
        Z.fetch_add(1, Ordering::Relaxed);
    }
}

fn read_y_then_x() {
    while !Y.load(Ordering::SeqCst) {}
    if X.load(Ordering::SeqCst) {
        Z.fetch_add(1, Ordering::Relaxed);
    }
}

fn main() {
    let mut jhs = Vec::new();
    jhs.push(thread::spawn(write_x)); // a
    jhs.push(thread::spawn(write_y)); // b
    jhs.push(thread::spawn(read_x_then_y)); // c
    jhs.push(thread::spawn(read_y_then_x)); // d
    for jh in jhs {
        jh.join().unwrap();
    }
    assert!(Z.load(Ordering::Relaxed) != 0);
}

假设我们不在我们的示例线程之间强制执行SeqCst。那么会怎样？线程c会循环，直到线程a翻转布尔值X，加载Y，如果为真，则增加Z。同样，对于线程d，除了b翻转布尔值Y，增加操作由X保护。为了使程序在所有线程挂起后不会崩溃，线程必须看到X和Y的翻转以相同的顺序发生。请注意，顺序本身并不重要，重要的是它对每个线程来说都是相同的。否则，存储和加载可能会以某种方式交错，从而避免增加。强烈鼓励读者自己尝试调整顺序。

构建同步

现在我们已经对 Rust 标准库中可用的原子原语有了良好的基础，并且还有坚实的理论基础，是时候在此基础上构建了。在过去几章中，我们一直在暗示我们的意图是从原语构建互斥锁和信号量，嗯，现在时机已经成熟。

互斥锁

现在我们已经理解了线性化和内存排序，让我们问自己一个问题。互斥锁 究竟 是什么？我们知道它作为一个原子对象具有以下属性：

• 互斥锁支持两种操作，锁定 和 解锁。

• 互斥锁要么是 锁定 的，要么是 未锁定 的。

• 操作 锁定 将将互斥锁移动到 锁定 状态，仅当互斥锁是 未锁定 的。完成 锁定 的线程被称为持有锁。

• 操作 解锁 将将互斥锁移动到 未锁定 状态，仅当互斥锁之前是 锁定 的，并且 解锁 的调用者是锁的持有者。

• 在程序顺序中，在 锁定 之后和之前发生的所有加载和存储操作不得移动到 锁定 操作之前或之后。

• 在程序顺序中，在 解锁 之前发生的所有加载和存储操作不得移动到 解锁 之后。

第二个到最后一个点很微妙。考虑一个软互斥锁，其锁只保留迁移后的加载和存储。这意味着加载/存储可以迁移到软互斥锁中，这很好，除非你的迁移是另一个软互斥锁的锁。考虑以下情况：

lock(m0)
unlock(m0)
lock(m1)
unlock(m1)

这可以重新排列为以下内容：

lock(m0)
lock(m1)
unlock(m0)
unlock(m1)

这里，unlock(m0) 已经在程序顺序中迁移到 m1 的互斥排他区域，导致程序死锁。这是一个问题。

你可能不会惊讶地了解到，到目前为止，关于互斥排他问题的研究已有几十年。互斥锁应该如何设计？公平性因素如何影响实现？后者是一个相当广泛的话题，避免线程 饥饿，我们在这里或多或少会避开这个问题。大部分历史研究都是针对没有并发控制概念的机器。Lamport 的面包店算法——参见 进一步阅读 部分——提供了任何硬件支持中都不存在的互斥排他，但假设读取和写入是顺序一致的，这个假设在现代内存层次结构中并不成立。在很大意义上，我们生活在一个非常美好的并发编程时代：我们的机器直接暴露同步原语，极大地简化了快速和正确同步机制的生产。

比较并设置互斥锁

首先，让我们看看一个非常简单的互斥锁实现，一个在循环中旋转直到正确条件出现的原子交换互斥锁。也就是说，让我们构建一个 自旋锁。这个互斥锁之所以这样命名，是因为每个在 lock 上阻塞的线程都在消耗 CPU，在它获得锁的条件上自旋。无论如何，你很快就会看到。我们首先放下我们的 Cargo.toml：

[package]
name = "synchro"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[[bin]]
name = "swap_mutex"
doc = false

[[bin]]
name = "status_demo"
doc = false

[[bin]]
name = "mutex_status_demo"
doc = false

[[bin]]
name = "spin_mutex_status_demo"
doc = false

[[bin]]
name = "queue_spin"
doc = false

[[bin]]
name = "crossbeam_queue_spin"
doc = false

[dependencies]
crossbeam = { git = "https://github.com/crossbeam-rs/crossbeam.git", rev = "89bd6857cd701bff54f7a8bf47ccaa38d5022bfb" }

[dev-dependencies]
quickcheck = "0.6"

现在，我们需要 src/lib.rs:

extern crate crossbeam;

mod queue;
mod swap_mutex;
mod semaphore;

pub use semaphore::*;
pub use swap_mutex::*;
pub use queue::*;

这里有相当一部分内容我们暂时不会直接使用，但我们会很快涉及到。现在，让我们深入到src/swap_mutex.rs文件。首先，是我们的前言：

extern crate crossbeam;

mod queue;
mod swap_mutex;
mod semaphore;

到这个阶段，这里并没有太多惊喜。我们看到通常的导入，还有一些新的导入——AtomicBool和Ordering，正如之前讨论的那样。我们自行实现了Send和Sync——在上一章中讨论过——因为虽然我们可以证明我们的SwapMutex<T>是线程安全的，但 Rust 不能。SwapMutex<T>很小：

pub struct SwapMutex<T> {
    locked: AtomicBool,
    data: *mut T,
}

字段locked是一个AtomicBool，我们将使用它来在线程之间提供隔离。这个想法很简单——如果一个线程出现并发现locked是false，那么这个线程可以获取锁，否则它必须自旋。还值得注意的是，我们的实现稍微有些冒险，因为它保留了对T的原始指针。截至撰写本书时，Rust 标准库std::sync::Mutex将其内部数据存储在UnsafeCell中，而我们无法在稳定版本中访问它。在这个实现中，我们只是存储指针，并不通过它进行任何操作。尽管如此，我们仍然必须小心处理SwapMutex的析构。创建SwapMutex的方式可能正如你所预期的那样：

impl<T> SwapMutex<T> {
    pub fn new(t: T) -> Self {
        let boxed_data = Box::new(t);
        SwapMutex {
            locked: AtomicBool::new(false),
            data: Box::into_raw(boxed_data),
        }
    }

T被移动到SwapMutex中，然后我们将其装箱以获取其原始指针。这是必要的，以避免栈值被推入SwapMutex，然后在栈帧改变时迅速消失，所有这些都已经在第二章中详细讨论过，顺序 Rust 性能和测试。互斥锁始终处于未锁定状态，否则将无法获取它。现在，让我们看看如何锁定互斥锁：

    pub fn lock(&self) -> SwapMutexGuard<T> {
        while self.locked.swap(true, Ordering::AcqRel) {
            thread::yield_now();
        }
        SwapMutexGuard::new(self)
    }

与标准库Mutex相比，API 略有不同。一方面，SwapMutex不跟踪中毒，因此，如果调用锁，则保证会返回一个名为SwapMutexGuard的守卫。然而，SwapMutex是基于作用域的；就像标准库MutexGuard一样，没有必要——也没有能力——永远调用显式的解锁。不过，确实有一个解锁操作，用于SwapMutexGuard的析构：

    fn unlock(&self) -> () {
        assert!(self.locked.load(Ordering::Relaxed) == true);
        self.locked.store(false, Ordering::Release);
    }

在这个简单的互斥锁中，要解锁只需要将locked字段设置为false，但在确认调用线程确实有权解锁互斥锁之前不要这样做。

现在，我们能否说服自己这个互斥锁是正确的？让我们逐一检查我们的标准：

“互斥锁支持两种操作，锁定和解锁。”

检查。接下来：

“互斥锁要么是锁定的，要么是未锁定。”

通过布尔值标记来检查，最后：

“操作锁定将互斥锁移动到锁定状态，当且仅当互斥锁处于未锁定状态。完成锁定操作的线程被称为持有锁定。”

让我们讨论一下 AtomicBool::swap 的作用。完整的类型是 swap(&self, val: bool, order: Ordering) -> bool，该函数根据其名称执行你可能会期望的操作；它根据传递的排序原子地交换 self 中的布尔值与 val 中的布尔值，并返回前一个值。在这里，因此，每个线程都在竞争将 true 写入锁定标志，并且由于交换的原子性，一次只有一个线程会看到返回的前一个值为 false。写入 false 的线程现在是锁的持有者，返回 SwapMutexGuard。锁定 SwapMutex 只能对未锁定的 SwapMutex 进行，并且是排他性地对其他线程进行的。

“解锁操作将把互斥锁移动到未锁定状态，如果且仅当互斥锁之前是锁定状态，并且解锁的调用者是锁的持有者。”

让我们考虑解锁。首先回忆一下，只有从 SwapMutexGuard 调用才有可能进行操作，所以调用者有权限解锁 SwapMutex 的断言是对锁故障的检查：一次只有一个线程可以持有 SwapMutex，因此内存中只会存在一个 SwapMutexGuard。由于 Release 排序的性质，我们保证 locked 的 Relaxed 加载将在存储之前发生，所以可以保证当存储发生时，locked 的值将是 true。只有锁的持有者才能解锁它，并且这个属性也得到了满足。

“在程序顺序中在锁之前和之后发生的所有加载和存储操作不得在锁之前或之后移动。”

这直接源于 AcqRel 排序的行为。

“在程序顺序中在解锁之前发生的所有加载和存储操作不得移动到解锁之后。”

这源于 Release 排序的行为。

嗯，我们得到了一个互斥锁。它不是一个特别节能的互斥锁，但它确实具有基本属性。为了完整性，以下是其余的内容：

impl<T> Drop for SwapMutex<T> {
    fn drop(&mut self) {
        let data = unsafe { Box::from_raw(self.data) };
        drop(data);
    }
}

pub struct SwapMutexGuard<'a, T: 'a> {
    __lock: &'a SwapMutex<T>,
}

impl<'a, T> SwapMutexGuard<'a, T> {
    fn new(lock: &'a SwapMutex<T>) -> SwapMutexGuard<'a, T> {
        SwapMutexGuard { __lock: lock }
    }
}

impl<'a, T> Deref for SwapMutexGuard<'a, T> {
    type Target = T;

    fn deref(&self) -> &T {
        unsafe { &*self.__lock.data }
    }
}

impl<'a, T> DerefMut for SwapMutexGuard<'a, T> {
    fn deref_mut(&mut self) -> &mut T {
        unsafe { &mut *self.__lock.data }
    }
}

impl<'a, T> Drop for SwapMutexGuard<'a, T> {
    #[inline]
    fn drop(&mut self) {
        self.__lock.unlock();
    }
}

现在，让我们用 SwapMutex 来构建一些东西。在 src/bin/swap_mutex.rs 中，我们将复制上一章中的桥接问题，但这次是在 SwapMutex 上，再加上一些现在我们知道如何使用原子操作的一些花哨的附加功能。下面是前言：

extern crate synchro;

use std::sync::atomic::{AtomicUsize, Ordering};
use std::sync::Arc;
use synchro::SwapMutex;
use std::{thread, time};

#[derive(Debug)]
enum Bridge {
    Empty,
    Left(u8),
    Right(u8),
}

足够熟悉了。我们引入了 SwapMutex，并定义了 Bridge。相当不出所料的内容。继续：

static LHS_TRANSFERS: AtomicUsize = AtomicUsize::new(0);
static RHS_TRANSFERS: AtomicUsize = AtomicUsize::new(0);

虽然这是新的。Rust 中的静态是编译时全局变量。我们偶尔看到它们的静态生命周期在周围飘荡，但从未对此发表评论。静态将成为二进制文件的一部分，并且为静态所需的任何初始化代码都必须在编译时评估，并且是线程安全的。我们在程序顶部创建了两个静态AtomicUsizes。为什么？前一个绳桥实现的主要问题之一是它的沉默。你当然可以在调试器中观察它，但这很慢，而且不会给你的朋友留下深刻印象。现在，我们有了原子操作，我们将要做的就是让桥的每一侧都统计有多少狒狒通过。LHS_TRANSFERS是向左移动的狒狒的数量，RHS_TRANSFERS是相反的方向。这次我们将桥的左右两侧分解成函数：

fn lhs(rope: Arc<SwapMutex<Bridge>>) -> () {
    loop {
        let mut guard = rope.lock();
        match *guard {
            Bridge::Empty => {
                *guard = Bridge::Right(1);
            }
            Bridge::Right(i) => {
                if i < 5 {
                    *guard = Bridge::Right(i + 1);
                }
            }
            Bridge::Left(0) => {
                *guard = Bridge::Empty;
            }
            Bridge::Left(i) => {
                LHS_TRANSFERS.fetch_add(1, Ordering::Relaxed);
                *guard = Bridge::Left(i - 1);
            }
        }
    }
}

fn rhs(rope: Arc<SwapMutex<Bridge>>) -> () {
    loop {
        let mut guard = rope.lock();
        match *guard {
            Bridge::Empty => {
                *guard = Bridge::Left(1);
            }
            Bridge::Left(i) => {
                if i < 5 {
                    *guard = Bridge::Left(i + 1);
                }
            }
            Bridge::Right(0) => {
                *guard = Bridge::Empty;
            }
            Bridge::Right(i) => {
                RHS_TRANSFERS.fetch_add(1, Ordering::Relaxed);
                *guard = Bridge::Right(i - 1);
            }
        }
    }
}

这应该足够熟悉了，来自上一章，但请注意，传输计数器现在正在更新。我们使用了Relaxed排序——增量保证会到达，但它们严格发生在修改守卫之前或之后并不是特别必要。最后，是main函数：

fn main() {
    let mtx: Arc<SwapMutex<Bridge>> = Arc::new(SwapMutex::new(Bridge::Empty));

    let lhs_mtx = Arc::clone(&mtx);
    let _lhs = thread::spawn(move || lhs(lhs_mtx));
    let _rhs = thread::spawn(move || rhs(mtx));

    let one_second = time::Duration::from_millis(1_000);
    loop {
        thread::sleep(one_second);
        println!(
            "Transfers per second:\n    LHS: {}\n    RHS: {}",
            LHS_TRANSFERS.swap(0, Ordering::Relaxed),
            RHS_TRANSFERS.swap(0, Ordering::Relaxed)
        );
    }
}

我们可以看到，这里已经设置了互斥锁，创建了线程，并且主线程花费时间在一个无限循环中打印传输率的信息。这是通过在一秒钟间隔中暂停线程，交换传输计数器与零并打印前一个值来完成的。输出看起来像这样：

> cargo build
> ./target/debug/swap_mutex
Transfers per second:
    LHS: 787790
    RHS: 719371
Transfers per second:
    LHS: 833537
    RHS: 770782
Transfers per second:
    LHS: 848662
    RHS: 776678
Transfers per second:
    LHS: 783769
    RHS: 726334
Transfers per second:
    LHS: 828969
    RHS: 761439

具体的数字将根据您的系统而变化。请注意，在某些情况下，这些数字也不是非常接近。SwapMutex不是公平的。

一个错误的原子队列

在我们构建任何其他东西之前，我们需要一个关键的数据结构——一个无界队列。在第五章中，锁——互斥锁、条件变量、屏障和读写锁，我们讨论了由互斥锁保护在两端的有界双端队列。现在，我们正在从事构建同步的工作，不能使用互斥锁的方法。我们的目标是创建一个无界先进先出数据结构，它没有锁，永远不会让入队或出队操作死锁，并且可以线性化为顺序队列。结果证明，有一个相当直接的数据结构可以实现这个目标；迈克尔和斯科特队列，在他们的 1995 年论文简单、快速和实用的非阻塞和阻塞并发队列算法中介绍。鼓励读者在继续我们这里的讨论之前快速浏览一下那篇论文，但这不是严格必要的。

有一个警告。我们的实现将是错误的。仔细的读者会注意到我们正在紧密遵循论文。我们将展示的实现有两个，可能还有更多，问题，一个是主要且无法解决的，另一个可以通过一些小心处理来解决。这两个问题都相当微妙。让我们深入探讨。

Queue 定义在 src/queue.rs 中，其前导部分如下：

use std::ptr::null_mut;
use std::sync::atomic::{AtomicPtr, Ordering};

unsafe impl<T: Send> Send for Queue<T> {}
unsafe impl<T: Send> Sync for Queue<T> {}

立刻从 null_mut 可以看出，我们将要处理原始指针。AtomicPtr 是新的，尽管我们在本章前面提到了它。原子指针将原始指针——*mut T——适配为适合原子操作。与 AtomicPtr 相关的运行时开销为零；Rust 文档指出，该类型与 *mut T 具有相同的内存表示。现代机器暴露出指令，使程序员能够原子地操作内存。正如预期的那样，能力因处理器而异。LLVM 和因此 Rust 通过 AtomicPtr 暴露这些原子内存操作能力，允许在顺序语言中原子地执行指针操作。在实践中，这意味着我们可以开始设置指针操作的前置/同步因果关系，这对于构建数据结构至关重要。

这里是下一部分：

struct Node<T> {
    value: *const T,
    next: AtomicPtr<Node<T>>,
}

impl<T> Default for Node<T> {
    fn default() -> Self {
        Node {
            value: null_mut(),
            next: AtomicPtr::default(),
        }
    }
}

impl<T> Node<T> {
    fn new(val: T) -> Self {
        Node {
            value: Box::into_raw(Box::new(val)),
            next: AtomicPtr::default(),
        }
    }
}

上一章中的双端队列的内部是一个单一的、连续的块。我们这里不是采取这种方法。相反，每个插入队列的元素都将获得一个 Node，该 Node 将指向下一个 Node，而这个 Node 可能存在也可能不存在。它是一个链表。在原子上下文中实现连续块的方法有点困难——尽管这是完全可能的，并且在 进一步阅读 部分的论文中有所讨论——并且将归结为连续块的链表。对于我们这里的用途来说，这比它值得的麻烦要多：

struct InnerQueue<T> {
    head: AtomicPtr<Node<T>>,
    tail: AtomicPtr<Node<T>>,
}

一个需要注意的关键点是 Node 持有一个指向堆分配的 T 的指针，而不是直接持有 T。在先前的代码中，我们有 Queue<T> 的 InnerQueue<T>，这是这本书和其他地方详细描述的常规内/外结构。为什么要注意 Node 不直接持有其 T 呢？Queue<T> 的头部的值永远不会被检查。Queue 的头部是一个哨兵。当创建 InnerQueue 时，我们将看到以下内容：

impl<T> InnerQueue<T> {
    pub fn new() -> Self {
        let node = Box::into_raw(Box::new(Node::default()));
        InnerQueue {
            head: AtomicPtr::new(node),
            tail: AtomicPtr::new(node),
        }
    }

如预期的那样，InnerQueue 的 head 和 tail 都指向同一个无意义的 Node。实际上，初始值是 null。原子数据结构在内存回收方面存在问题，因为协调释放是困难的，并且必须只执行一次。通过依赖 Rust 的类型系统，可以稍微缓解这个问题，但这仍然是一个非平凡的工程，并且是研究的一个活跃领域。在这里，我们注意到我们非常小心地只分配一次元素的拥有权。作为一个原始指针，它可以一次分配多次，但这条路径会导致双重释放。InnerQueue 将 *const T 转换为 T——这是一个不安全的操作——并且永远不会再次解引用 *const T，允许调用者在合适的时间执行释放操作：

    pub unsafe fn enq(&mut self, val: T) -> () {
        let node = Box::new(Node::new(val));
        let node: *mut Node<T> = Box::into_raw(node);

        loop {
            let tail: *mut Node<T> = self.tail.load(Ordering::Acquire);
            let next: *mut Node<T> = 
            (*tail).next.load(Ordering::Relaxed);
            if tail == self.tail.load(Ordering::Relaxed) {
                if next.is_null() {
                    if (*tail).next.compare_and_swap(next, node, 
                     Ordering::Relaxed) == next {
                        self.tail.compare_and_swap(tail, node, 
                         Ordering::Release);
                        return;
                    }
                }
            } else {
                self.tail.compare_and_swap(tail, next, 
                Ordering::Release);
            }
        }
    }

这是enq操作，由于涉及原始指针操作，因此标记为不安全。这是一个需要考虑的重要点——AtomicPtr必然需要使用原始指针。这里有很多事情在进行，所以让我们将其分解成更小的部分：

    pub unsafe fn enq(&mut self, val: T) -> () {
        let node = Box::new(Node::new(val));
        let node: *mut Node<T> = Box::into_raw(node);

这里，我们正在为val构造Node。注意我们正在使用与之前章节中经常使用的相同的装箱，即into_raw方法。这个节点在队列中还没有位置，调用线程也没有对队列持有独占锁。插入将不得不在其他插入过程中进行：

        loop {
            let tail: *mut Node<T> = self.tail.load(Ordering::Acquire);
            let next: *mut Node<T> = 
            (*tail).next.load(Ordering::Relaxed);

考虑到这一点，插入尝试可能会失败。在队列中入队一个元素发生在尾部分，我们加载并调用last的指针。tail之后的下一个节点称为next。在顺序队列中，我们可以保证tail的下一个是 null，但在这里并非如此。考虑在加载tail指针和加载next指针之间，另一个线程可能已经完成了enq操作。

入队操作可能需要尝试多次，才能达到成功的条件。这些条件是结构体的尾部分，接下来是null：

            if tail == self.tail.load(Ordering::Relaxed) {
                if next.is_null() {

注意，第一次加载tail是Acquire，而可能的存储操作，无论是哪个分支，都是Release。这满足了我们的Acquire/Release需求，关于锁定原语。这里的所有其他存储和加载操作都是明显的Relaxed。我们如何确保我们没有意外地覆盖写入，或者由于这是一个链表，在内存中切断它们？这就是AtomicPtr发挥作用的地方：

                    if (*tail).next.compare_and_swap(next, node, 
                     Ordering::Relaxed) == next {
                        self.tail.compare_and_swap(tail, node, 
                         Ordering::Release);
                        return;
                    }

完全有可能，当我们检测到入队正确条件的时候，另一个线程已经被调度，已经检测到入队正确条件，并且已经被入队。我们尝试使用(*last).next.compare_and_swap(next, node, Ordering::Relaxed)将新节点插入，也就是说，我们比较当前last的next，如果并且只有如果这成功了——那就是== next部分——我们尝试将tail设置为节点指针，再次使用比较和交换。如果这两个都成功了，那么新元素已经完全入队。然而，tail的交换可能会失败，在这种情况下，链表被正确设置，但tail指针偏移了。enq和deq操作都必须意识到它们可能会遇到需要调整tail指针的情况。实际上，这就是enq函数结束的方式：

                }
            } else {
                self.tail.compare_and_swap(tail, next, 
                 Ordering::Release);
            }
        }
    }

在 x86 上，所有这些 Relaxed 操作都更为严格，但在 ARMv8 上会有各种重排序。在所有修改之间建立因果关系非常重要且困难。例如，如果我们交换了 tail 指针然后是 tail 指针的 next，我们就会使自己面临破坏链表或根据线程对内存的视图创建整个孤立链的风险。deq 操作类似：

    pub unsafe fn deq(&mut self) -> Option<T> {
        let mut head: *mut Node<T>;
        let value: T;
        loop {
            head = self.head.load(Ordering::Acquire);
            let tail: *mut Node<T> = self.tail.load(Ordering::Relaxed);
            let next: *mut Node<T> = 
            (*head).next.load(Ordering::Relaxed);
            if head == self.head.load(Ordering::Relaxed) {
                if head == tail {
                    if next.is_null() {
                        return None;
                    }
                    self.tail.compare_and_swap(tail, next, 
                     Ordering::Relaxed);
                } else {
                    let val: *mut T = (*next).value as *mut T;
                    if self.head.compare_and_swap(head, next, 
                    Ordering::Release) == head {
                        value = *Box::from_raw(val);
                        break;
                    }
                }
            }
        }
        let head: Node<T> = *Box::from_raw(head);
        drop(head);
        Some(value)
    }
}

这个函数是一个循环，就像 enq 一样，我们在其中寻找正确的条件和情况来出队一个元素。第一个外部 if 子句检查 head 是否在我们身上移动，而内部第一个分支是关于一个没有元素的队列，其中第一个和最后一个都是指向相同存储的指针。注意，如果 next 不是空，我们会在再次循环回来进行另一次出队尝试之前尝试修复一个部分完成的节点链表。

这是因为，正如之前讨论的那样，enq 可能不会完全成功。当 head 和 tail 不相等时，会触发第二个内部循环，这意味着有一个元素需要被取出。正如内联注释所解释的，当第一个元素没有在我们身上移动时，我们就会给出元素 T 的所有权，但我们非常小心，直到我们可以确定我们将是唯一一个将管理该元素的线程，我们才不会解引用指针。我们可以因为只有一个线程能够交换调用线程当前持有的特定第一个和下一个对。

在所有这些之后，实际的 Queue<T> 外部函数有点令人失望：

pub struct Queue<T> {
    inner: *mut InnerQueue<T>,
}

impl<T> Clone for Queue<T> {
    fn clone(&self) -> Queue<T> {
        Queue { inner: self.inner }
    }
}

impl<T> Queue<T> {
    pub fn new() -> Self {
        Queue {
            inner: Box::into_raw(Box::new(InnerQueue::new())),
        }
    }

    pub fn enq(&self, val: T) -> () {
        unsafe { (*self.inner).enq(val) }
    }

    pub fn deq(&self) -> Option<T> {
        unsafe { (*self.inner).deq() }
    }

我们已经通过推理完成了实现，并且，希望亲爱的读者，你已经被说服这个想法应该能够工作。真正考验的地方在于测试：

#[cfg(test)]
mod test {
    extern crate quickcheck;

    use super::*;
    use std::collections::VecDeque;
    use std::sync::atomic::AtomicUsize;
    use std::thread;
    use std::sync::Arc;
    use self::quickcheck::{Arbitrary, Gen, QuickCheck, TestResult};

    #[derive(Clone, Debug)]
    enum Op {
        Enq(u32),
        Deq,
    }

    impl Arbitrary for Op {
        fn arbitrary<G>(g: &mut G) -> Self
        where
            G: Gen,
        {
            let i: usize = g.gen_range(0, 2);
            match i {
                0 => Op::Enq(g.gen()),
                _ => Op::Deq,
            }
        }
    }

这是我们在这本书的其他地方看到过的通常的 test 前置代码。我们定义一个 Op 枚举来驱动解释器风格的 quickcheck test，我们在这里称之为 sequential：

    #[test]
    fn sequential() {
        fn inner(ops: Vec<Op>) -> TestResult {
            let mut vd = VecDeque::new();
            let q = Queue::new();

            for op in ops {
                match op {
                    Op::Enq(v) => {
                        vd.push_back(v);
                        q.enq(v);
                    }
                    Op::Deq => {
                        assert_eq!(vd.pop_front(), q.deq());
                    }
                }
            }
            TestResult::passed()
        }
        QuickCheck::new().quickcheck(inner as fn(Vec<Op>) -> 
        TestResult);
    }

我们有一个 VecDeque 作为模型；我们知道它是一个合适的队列。然后，在不涉及任何真实并发的情况下，我们确认 Queue 的行为类似于 VecDeque。至少在顺序设置中，Queue 将会工作。现在，对于并行 test：

    fn parallel_exp(total: usize, enqs: u8, deqs: u8) -> bool {
        let q = Queue::new();
        let total_expected = total * (enqs as usize);
        let total_retrieved = Arc::new(AtomicUsize::new(0));

        let mut ejhs = Vec::new();
        for _ in 0..enqs {
            let mut q = q.clone();
            ejhs.push(
                thread::Builder::new()
                    .spawn(move || {
                        for i in 0..total {
                            q.enq(i);
                        }
                    })
                    .unwrap(),
            );
        }

        let mut djhs = Vec::new();
        for _ in 0..deqs {
            let mut q = q.clone();
            let total_retrieved = Arc::clone(&total_retrieved);
            djhs.push(
                thread::Builder::new()
                    .spawn(move || {
                        while total_retrieved.load(Ordering::Relaxed) 
                        != total_expected {
                            if q.deq().is_some() {
                                total_retrieved.fetch_add(1, 
                                Ordering::Relaxed);
                            }
                        }
                    })
                    .unwrap(),
            );
        }

        for jh in ejhs {
            jh.join().unwrap();
        }
        for jh in djhs {
            jh.join().unwrap();
        }

        assert_eq!(total_retrieved.load(Ordering::Relaxed), 
        total_expected);
        true
    }

我们设置了两组线程，一组负责入队，另一组负责出队。入队线程将total数量的项目推入Queue，而出队线程则拉取，直到一个共享在每个出队线程之间的计数器达到 bingo。最后，回到主test线程，我们确认检索到的总项目数与预期的项目数相同。我们的出队线程可能会因为 while 循环的检查和q.deq调用的竞争而读取队列的末尾，这反而对我们有利，因为确认队列允许出队不超过入队元素的数量。此外，当运行test时，没有出现双重释放崩溃。这个内部的test函数被使用了两次，一次是在重复运行中，然后又在quickcheck设置中：

    #[test]
    fn repeated() {
        for i in 0..10_000 {
            println!("{}", i);
            parallel_exp(73, 2, 2);
        }
    }

    #[test]
    fn parallel() {
        fn inner(total: usize, enqs: u8, deqs: u8) -> TestResult {
            if enqs == 0 || deqs == 0 {
                TestResult::discard()
            } else {
                TestResult::from_bool(parallel_exp(total, enqs, deqs))
            }
        }
        QuickCheck::new().quickcheck(inner as fn(usize, u8, u8) -> 
        TestResult);
    }
}

这里有什么问题？如果你运行test套件，你可能会或可能不会遇到一个问题。它们相当不可能，尽管我们很快就会看到一种可靠触发最坏情况的方法。我们实现遇到的第一问题是 ABA 问题。在比较和交换操作中，指针A将被某个线程与B交换。在第一个线程完成检查之前，另一个线程将A与C交换，然后C又回到A。然后第一个线程被重新调度，并执行其将A比较和交换为B的操作，而不知道A实际上并不是交换开始时的那个A。这将导致队列的链表块指向错误，可能指向队列不应拥有的内存。这已经足够糟糕了。还能更糟吗？

让我们用这个结构引起使用后释放违规。我们的演示程序很短，位于src/bin/queue_spin.rs：

extern crate synchro;

use synchro::Queue;
use std::thread;

fn main() {
    let q = Queue::new();

    let mut jhs = Vec::new();

    for _ in 0..4 {
        let eq = q.clone();
        jhs.push(thread::spawn(move || {
            let mut i = 0;
            loop {
                eq.enq(i);
                i += 1;
                eq.deq();
            }
        }))
    }

    for jh in jhs {
        jh.join().unwrap();
    }
}

程序创建了四个线程，每个线程尽可能快地按顺序入队和出队，它们之间没有任何协调。至少需要有两个线程，否则队列是顺序使用的，问题就不会存在：

> time cargo run --bin queue_spin
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/queue_spin`
Segmentation fault

real    0m0.588s
user    0m0.964s
sys     0m0.016s

ouch。这根本没花什么时间。让我们用调试器看看程序。我们将使用lldb，但如果你使用gdb，结果将是相同的：

> lldb-3.9 target/debug/queue_spin
(lldb) target create "target/debug/queue_spin"
Current executable set to 'target/debug/queue_spin' (x86_64).
(lldb) run
Process 12917 launched: '/home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/synchro/target/debug/queue_spin' (x86_64)
Process 12917 stopped
* thread #2: tid = 12920, 0x0000555555560585 queue_spin`_$LT$synchro..queue..InnerQueue$LT$T$GT$$GT$::deq::heefaa8c9b1d410ee(self=0x00007ffff6c2a010) + 261 at queue.rs:78, name = 'queue_spin', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000555555560585 queue_spin`_$LT$synchro..queue..InnerQueue$LT$T$GT$$GT$::deq::heefaa8c9b1d410ee(self=0x00007ffff6c2a010) + 261 at queue.rs:78
   75                       }
   76                       self.tail.compare_and_swap(tail, next, 
                            Ordering::Relaxed);
   77                   } else {
-> 78                       let val: *mut T = (*next).value as *mut T;
   79                       if self.head.compare_and_swap(head, next, 
                            Ordering::Release) == head {
   80                           value = *Box::from_raw(val);
   81                           break;
  thread #3: tid = 12921, 0x0000555555560585 queue_spin`_$LT$synchro..queue..InnerQueue$LT$T$GT$$GT$::deq::heefaa8c9b1d410ee(self=0x00007ffff6c2a010) + 261 at queue.rs:78, name = 'queue_spin', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000555555560585 queue_spin`_$LT$synchro..queue..InnerQueue$LT$T$GT$$GT$::deq::heefaa8c9b1d410ee(self=0x00007ffff6c2a010) + 261 at queue.rs:78
   75                       }
   76                       self.tail.compare_and_swap(tail, next, 
                            Ordering::Relaxed);
   77                   } else {
-> 78                       let val: *mut T = (*next).value as *mut T;
   79                       if self.head.compare_and_swap(head, next, 
                            Ordering::Release) == head {
   80                           value = *Box::from_raw(val);
   81                           break;

好吧，看看这个！只是为了确认：

(lldb) p next
(synchro::queue::Node<i32> *) $0 = 0x0000000000000000

我们能再增加一个吗？是的：

(lldb) Process 12893 launched: '/home/blt/projects/us/troutwine/concurrency_in_rust/external_projects/synchro/target/debug/queue_spin' (x86_64)
Process 12893 stopped
* thread #2: tid = 12896, 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502, name = 'queue_spin', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
    frame #0: 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502
  thread #3: tid = 12897, 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502, name = 'queue_spin', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
    frame #0: 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502
  thread #4: tid = 12898, 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502, name = 'queue_spin', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
    frame #0: 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502
  thread #5: tid = 12899, 0x000055555555fb3e queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502, name = 'queue_spin', stop reason = signal SIGSEGV: invalid address (fault address: 0x8)
    frame #0: 0x000055555555fb3e
queue_spin`core::sync::atomic::atomic_load::hd37078e3d501f11f(dst=0x0000000000000008, order=Relaxed) + 78 at atomic.rs:1502

在第一个例子中，头指针指向 null，这将在队列为空时发生，但这个特定的分支只有在队列为空时才会被击中。这里发生了什么？实际上，这里有一个讨厌的竞争，它与释放有关。让我们再次看看deq，这次带有行号：

 64    pub unsafe fn deq(&mut self) -> Option<T> {
 65        let mut head: *mut Node<T>;
 66        let value: T;
 67        loop {
 68            head = self.head.load(Ordering::Acquire);
 69            let tail: *mut Node<T> = 
               self.tail.load(Ordering::Relaxed);
 70            let next: *mut Node<T> = 
               (*head).next.load(Ordering::Relaxed);
 71            if head == self.head.load(Ordering::Relaxed) {
 72                if head == tail {
 73                    if next.is_null() {
 74                        return None;
 75                    }
 76                    self.tail.compare_and_swap(tail, next, 
                       Ordering::Relaxed);
 77                } else {
 78                    let val: *mut T = (*next).value as *mut T;
 79                    if self.head.compare_and_swap(head, next,  
                       Ordering::Release) == head {
 80                        value = *Box::from_raw(val);
 81                        break;
 82                    }
 83                }
 84            }
 85        }
 86        let head: Node<T> = *Box::from_raw(head);
 87        drop(head);
 88        Some(value)
 89    }

假设有四个线程，A 到 D。线程 A 到达第 78 行并停止。此时，线程 A 拥有一个 head、一个 tail 和一个 next，它们指向内存中的一个合理的链表。现在，线程 B、C 和 D 各自行使多次 enq 和 deq 操作，使得当 A 唤醒时，A 的头指针指向的链表已经不复存在。实际上，头节点本身已经被释放，但 A 很幸运，操作系统还没有覆盖它的内存。

线程 A 唤醒并执行第 78 行，但接下来却指向了无意义的内容，整个程序崩溃。或者，假设我们有两个线程，A 和 B。线程 A 唤醒并通过到第 70 行并停止。线程 B 唤醒并且非常幸运，一直前进到第 88 行，释放头节点。操作系统感觉到了自己的力量，覆盖了 A 指向的内存。然后线程 A 唤醒，触发 (*head).next.load(Ordering::Relaxed)，随后崩溃。这里有很多不同的可能性。它们之间的共同点是，在仍有未解决的对一个或多个节点的引用时发生释放。实际上，Michael 和 Scott 的论文确实提到了这个问题，但只是简要地提了一下，很容易被忽略：

“为了获得各种指针的一致值，我们依赖于一系列的读取操作，这些操作重新检查早期值以确保它们没有改变。这些读取序列与 Prakash 等人（我们需要检查一个共享变量而不是两个）的快照类似，但更简单。可以使用类似的技术来防止 Stone 的阻塞算法中的竞争条件。我们使用 Treiber 的简单高效的非阻塞栈算法来实现非阻塞的空闲列表。”

这里的关键思想是重新检查早期值的读取序列和空闲列表。通过检查我们发现，比较并交换一个已更改的值——ABA 问题——会导致我们的实现指向空间。此外，立即释放节点将使我们即使在没有比较并交换的情况下也容易崩溃。Michael 和 Scott 做的是创建一种最小化的内存管理；而不是删除节点，他们把它们移动到空闲列表中，以便稍后重用或删除。空闲列表可以是线程本地的，在这种情况下，你可以避免昂贵的同步，但仍然有点难以确保你的线程本地空闲列表不与另一个线程的指针相同。

纠正错误队列的选项

我们应该怎么做？实际上，文献中有很多选项。Hart、McKenney、Brown 和 Walpole 在 2007 年的论文《无锁同步的内存回收性能》中讨论了四种，并附上了它们原始论文的引用：

• 基于静默状态的回收（QSRB）：应用允许的信号静默'时间段进行回收

• 基于时代的回收（EBR）：应用程序通过在时代中移动内存来使用结构，以确定何时允许回收

• 基于危险指针的回收（HPBR）：线程协同并标记指针为回收时的危险状态

• 无锁引用计数（LFRC）：指针携带一个原子计数器，用于跟踪其使用情况，线程使用这个计数器来确定安全的回收周期

静止状态回收通过让在共享并发结构上操作的线程在一段时间内发出已进入静止状态的信号来实现，这意味着对于已标记的状态，线程不会对共享结构内的引用提出任何要求。一个单独的回收操作者，可能是结构本身或处于静止状态的线程，寻找宽限期，在这个期限内回收存储是安全的，要么因为所有线程都已静止，要么因为一些相关子集已静止。这相当棘手，需要在代码中添加进入和退出静止状态的通告。Hart 等人指出，在撰写本文时，这种方法在 Linux 内核中很常见，在撰写本文时仍然如此。感兴趣的读者可以参考有关 Linux 内核读-拷贝-更新机制的现有文献。QSRB 作为一项技术的主要困难在于，在用户空间中并不总是清楚是否存在自然静止期；如果你错误地发出信号，你可能会遇到数据竞争。操作系统的上下文切换是一个自然静止期——相关的上下文在它们被调用回来之前不会操作任何东西——但在我看来，在我们的队列中，这样一个时期的存在并不那么清晰。QSRB 的好处是它是一种非常快速的技术，比以下任何其他方法都需要更少的线程同步。

基于时代的回收与 QSRB 类似，但它是与应用程序无关的。也就是说，应用程序通过一个中介层与存储交互，而这个层存储了足够的信息来决定何时到来宽限期。特别是，每个线程都会切换一个标志，表示它打算与共享数据交互，交互后，在离开时将标志切换到另一个方向。标志周期数被称为一个“时代”。一旦共享数据通过了足够的时代，线程将尝试回收存储。这种方法的好处是比 QSRB 更自动——应用程序开发者使用专门设计的中间类型——但缺点是在数据访问的两侧都需要一些同步——那些标志切换。（论文实际上介绍了一种第五种新的基于时代的回收方法，它改进了基于时代的复制，但需要应用程序开发者的提示。在某种程度上，它是一种 EBR/QSRB 混合方法。）

危险指针回收方案完全依赖于数据结构。其理念是每个涉及的线程都将保留一个危险指针的集合，每个指针对应于它打算执行的无锁操作。这个线程本地的危险指针集合被映射到某个回收系统中——可能是一个专用垃圾收集器或插件分配器——并且这个系统能够检查危险指针的状态。当一个线程打算对某些共享数据进行无锁操作时，它会将危险指针标记为受保护，不允许其回收。当线程完成操作后，它会标记共享数据不再受保护。根据上下文，共享数据现在可能可以回收，或者可能需要后续回收。就像 EBR 一样，HPBR 需要通过特殊结构访问共享数据，并且在同步方面有开销。此外，与 EBR 相比，实现可能需要更高的负担，但低于 QSRB。更难的是，如果你的数据结构传递对其内部存储的引用，这也需要危险指针。线程越多，你需要更多的危险指针列表。内存开销可能会迅速变得相当大。与宽限期方法相比，由于无需搜索引用不是危险的时间，危险指针在回收内存方面可以更快。HPBR 每个操作的开销更高，总体内存需求也更高，但在回收方面可能更有效。这是一个非同小可的细节。如果 QSBR 或 EBR 在分配操作阻塞 CPU 的系统上运行，这些方法可能永远找不到宽限期，最终耗尽系统内存。

最后一个是原子引用计数，类似于标准库中的Arc，但用于原子操作。这种方法并不特别快，每次访问引用计数器以及该计数器的分支都会产生开销，但它很简单，回收发生得很快。

除了引用计数之外，这些方法中的每一个都很难实现。但我们很幸运；crate 生态系统提供了一个基于纪元的回收实现和危险指针回收。相关的库是 crossbeam (crates.io/crates/crossbeam) 和 conc (crates.io/crates/conc)。我们将在下一章中详细讨论它们。Crossbeam 旨在成为 Rust 的libcds (github.com/khizmax/libcds)，并且已经为我们实现了一个 Michael 和 Scott 队列。让我们试一试。相关文件是src/bin/crossbeam_queue_spin.rs：

extern crate crossbeam;

use crossbeam::sync::MsQueue;
use std::sync::Arc;
use std::thread;

fn main() {
    let q = Arc::new(MsQueue::new());

    let mut jhs = Vec::new();

    for _ in 0..4 {
        let q = Arc::clone(&q);
        jhs.push(thread::spawn(move || {
            let mut i = 0;
            loop {
                q.push(i);
                i += 1;
                q.pop();
            }
        }))
    }

    for jh in jhs {
        jh.join().unwrap();
    }
}

这与queue_spin相当相似，只是enq现在是推送操作，而deq是pop操作。同样值得注意的是，MsQueue::pop是阻塞的。这种机制的实现非常巧妙；我们将在下一章中讨论这一点。

信号量

我们在第五章中简要讨论了信号量，锁 – Mutex, Condvar, Barriers, 和 RWLock，特别是关于来自小信号量的并发难题。现在，正如承诺的那样，是时候实现一个信号量了。信号量究竟是什么？类似于我们将互斥锁分析为原子对象，让我们考虑它：

• 信号量支持两种操作，wait和signal。

• 信号量有一个isize类型的value，用于跟踪信号量的可用资源容量。这个值只能由wait和signal操作修改。

• 操作wait会减少value的值。如果值小于零，则wait会阻塞调用线程，直到有值可用。如果值不小于零，则线程不会阻塞。

• 操作signal会增加value的值。在增加之后，如果值小于或等于零，则有一个或多个等待线程。其中一个线程会被唤醒。如果增加后的值大于零，则没有等待线程。

• 在程序顺序中发生在等待之前和之后的所有加载和存储操作不得移动到等待之前或之后。

• 在程序顺序中发生在信号之前的所有加载和存储操作不得移动到信号之后。

如果这看起来很熟悉，那是有很好的原因的。从某种角度看，互斥锁是一个只有一个可用资源的信号量；锁定互斥锁映射到wait，而信号映射到unwait。我们已指定了在信号量等待和信号过程中的加载和存储行为，以避免在互斥锁分析中先前确定的相同死锁行为。

前面的分解没有捕捉到的一些细微之处不会影响信号量的分析，但会影响编程模型。我们将构建一个具有固定资源的信号量。也就是说，当创建信号量时，程序员负责设置信号量中可用的最大总资源，并确保信号量以这些资源可用开始。某些信号量实现允许资源容量随时间变化。这些通常被称为计数信号量。我们的变体被称为有界信号量；这种类型中只有一个资源的子变体称为二进制信号量。等待线程的信号行为可能有所不同。我们将根据先来先服务的原则唤醒线程。

让我们深入探讨。我们的信号量实现位于src/semaphore.rs中，它非常简短：

use crossbeam::sync::MsQueue;

unsafe impl Send for Semaphore {}
unsafe impl Sync for Semaphore {}

pub struct Semaphore {
    capacity: MsQueue<()>,
}

impl Semaphore {
    pub fn new(capacity: usize) -> Self {
        let q = MsQueue::new();
        for _ in 0..capacity {
            q.push(());
        }
        Semaphore { capacity: q }
    }

    pub fn wait(&self) -> () {
        self.capacity.pop();
    }

    pub fn signal(&self) -> () {
        self.capacity.push(());
    }
}

哇！Crossbeam 的MsQueue在MsQueue::push和MsQueue::pop按该顺序由同一线程完成时具有正确的排序语义，其中pop有额外的优势，即阻塞直到队列变为空。因此，我们的信号量是一个容量总计为()的MsQueue。wait操作通过Acquire/Release排序减少value（队列中的()总数）。signal操作通过将额外的()推送到队列中并带有Release语义来增加信号量的value。编程错误可能导致wait/signal调用不是一对一的，我们可以通过 Mutex 和SwapMutex采取的相同Guard方法来解决此问题。底层队列线性化Guard——请参阅下一章以了解该讨论——因此我们的信号量也是如此。让我们试试这个。我们有一个项目内的程序来演示Semaphore的使用，src/bin/status_demo.rs：

extern crate synchro;

use std::sync::Arc;
use synchro::Semaphore;
use std::{thread, time};

const THRS: usize = 4;
static mut COUNTS: &'static mut [u64] = &mut [0; THRS];
static mut STATUS: &'static mut [bool] = &mut [false; THRS];

fn worker(id: usize, gate: Arc<Semaphore>) -> () {
    unsafe {
        loop {
            gate.wait();
            STATUS[id] = true;
            COUNTS[id] += 1;
            STATUS[id] = false;
            gate.signal();
        }
    }
}

fn main() {
    let semaphore = Arc::new(Semaphore::new(1));

    for i in 0..THRS {
        let semaphore = Arc::clone(&semaphore);
        thread::spawn(move || worker(i, semaphore));
    }

    let mut counts: [u64; THRS] = [0; THRS];
    loop {
        unsafe {
            thread::sleep(time::Duration::from_millis(1_000));
            print!("|");
            for i in 0..THRS {
                print!(" {:>5}; {:010}/sec |", STATUS[i], 
                       COUNTS[i] - counts[i]);
                counts[i] = COUNTS[i];
            }
            println!();
        }
    }
}

我们设置THRS为总工作线程数，其职责是等待信号量，将它们的STATUS设置为 true，将COUNT加一，然后在发出信号量之前将STATUS设置为 false。可变静态数组对于任何程序来说都有些愚蠢的设置，但这是一个巧妙的技巧，并且在这里不会造成伤害，除了与优化器交互异常。如果你以发布模式编译此程序，你可能会发现优化器确定工作线程是一个无操作。main函数创建了一个容量为二的信号量，仔细地偏移了工作线程，然后无限期地打印出STATUS和COUNT的内容。在我的 x86 测试文章上的运行结果如下：

> ./target/release/status_demo
| false; 0000170580/sec |  true; 0000170889/sec |  true; 0000169847/sec | false; 0000169220/sec |
| false; 0000170262/sec | false; 0000170560/sec |  true; 0000169077/sec |  true; 0000169699/sec |
| false; 0000169109/sec | false; 0000169333/sec | false; 0000168422/sec | false; 0000168790/sec |
| false; 0000170266/sec |  true; 0000170653/sec | false; 0000168184/sec |  true; 0000169570/sec |
| false; 0000170907/sec | false; 0000171324/sec |  true; 0000170137/sec | false; 0000169227/sec |
...

以及从我的 ARMv7 机器上：

> ./target/release/status_demo
| false; 0000068840/sec |  true; 0000063798/sec | false; 0000063918/sec | false; 0000063652/sec |
| false; 0000074723/sec | false; 0000074253/sec |  true; 0000074392/sec |  true; 0000074485/sec |
|  true; 0000075138/sec | false; 0000074842/sec | false; 0000074791/sec |  true; 0000074698/sec |
| false; 0000075099/sec | false; 0000074117/sec | false; 0000074648/sec | false; 0000075083/sec |
| false; 0000075070/sec |  true; 0000074509/sec | false; 0000076196/sec |  true; 0000074577/sec |
|  true; 0000075257/sec |  true; 0000075682/sec | false; 0000074870/sec | false; 0000075887/sec |
...

二进制信号量，或者，一个更节省的互斥锁

我们的信号量与标准库的 Mutex 相比如何？我们的自旋锁Mutex呢？将此diff应用到status_demo：

diff --git a/external_projects/synchro/src/bin/status_demo.rs b/external_projects/synchro/src/bin/status_demo.rs
index cb3e850..fef2955 100644
--- a/external_projects/synchro/src/bin/status_demo.rs
+++ b/external_projects/synchro/src/bin/status_demo.rs
@@ -21,7 +21,7 @@ fn worker(id: usize, gate: Arc<Semaphore>) -> () {
 }

 fn main() {
-    let semaphore = Arc::new(Semaphore::new(2));
+    let semaphore = Arc::new(Semaphore::new(1));

     for i in 0..THRS {
         let semaphore = Arc::clone(&semaphore);

你将创建一个信号量状态演示的互斥锁变体。在我的 x86 测试文章上的数字如下：

| false; 0000090992/sec |  true; 0000090993/sec |  true; 0000091000/sec | false; 0000090993/sec |
| false; 0000090469/sec | false; 0000090468/sec |  true; 0000090467/sec |  true; 0000090469/sec |
|  true; 0000090093/sec | false; 0000090093/sec | false; 0000090095/sec | false; 0000090093/sec |

在容量为二的情况下，每秒是 170,000 次，所以有一个相当大的下降。让我们先与标准库互斥锁进行比较。这个适配在src/bin/mutex_status_demo.rs中：

use std::sync::{Arc, Mutex};
use std::{thread, time};

const THRS: usize = 4;
static mut COUNTS: &'static mut [u64] = &mut [0; THRS];
static mut STATUS: &'static mut [bool] = &mut [false; THRS];

fn worker(id: usize, gate: Arc<Mutex<()>>) -> () {
    unsafe {
        loop {
            let guard = gate.lock().unwrap();
            STATUS[id] = true;
            COUNTS[id] += 1;
            STATUS[id] = false;
            drop(guard);
        }
    }
}

fn main() {
    let mutex = Arc::new(Mutex::new(()));

    for i in 0..THRS {
        let mutex = Arc::clone(&mutex);
        thread::spawn(move || worker(i, mutex));
    }

    let mut counts: [u64; THRS] = [0; THRS];
    loop {
        unsafe {
            thread::sleep(time::Duration::from_millis(1_000));
            print!("|");
            for i in 0..THRS {
                print!(" {:>5}; {:010}/sec |", STATUS[i], 
                       COUNTS[i] - counts[i]);
                counts[i] = COUNTS[i];
            }
            println!();
        }
    }
}

很直接，对吧？在相同的 x86 测试文章上的数字如下：

| false; 0001856267/sec | false; 0002109238/sec |  true; 0002036852/sec |  true; 0002172337/sec |
| false; 0001887803/sec |  true; 0002072647/sec | false; 0002065467/sec |  true; 0002143558/sec |
| false; 0001848387/sec | false; 0002044828/sec |  true; 0002098595/sec |  true; 0002178304/sec |

让我们稍微慷慨一点，说标准库互斥锁每秒达到 2,000,000 次，而我们的二进制信号量每秒达到 170,000 次。那么自旋锁呢？在这个时候，我将避免列出源代码。只需确保导入SwapMutex并将其从标准库的Mutex相应地调整即可。这些数字如下：

|  true; 0012527450/sec | false; 0011959925/sec |  true; 0011863078/sec | false; 0012509126/sec |
|  true; 0012573119/sec | false; 0011949160/sec |  true; 0011894659/sec | false; 0012495174/sec |
| false; 0012481696/sec |  true; 0011952472/sec |  true; 0011856956/sec | false; 0012595455/sec |

你知道，这很有道理。自旋锁所做的最少工作量，每个线程都在燃烧 CPU 时间，以便在需要进入它们的临界区时立即到达。以下是我们的结果总结：

• 自旋锁互斥锁：每秒 11,000,000 次

• 标准库互斥锁：每秒 2,000,000 次

• 二进制信号量：每秒 170,000 次

鼓励读者在 Linux perf 中调查这些实现中的每一个。从这些结果中理解的关键不是这些实现中有哪一个比另一个更好或更差。而是它们适用于不同的目的。

例如，我们可以使用下一章中的技术来减少自旋锁互斥锁的 CPU 消耗。这可能会使其速度减慢一些，可能使其接近标准库 Mutex 的范围。在这种情况下，使用标准库 Mutex。

原子编程不是一件可以轻视的事情。正确实现它很困难，一个看似正确的实现可能并不遵守内存模型的因果属性。此外，仅仅因为一个事物是无锁的，并不意味着它在执行时会更快。

编写软件是关于识别和适应权衡。原子编程在这方面表现得尤为明显。

摘要

在本章中，我们讨论了现代 CPU 架构上可用的原子原语及其在 Rust 中的反映。我们构建了类似于第四章中讨论的同步和发送 – Rust 并发的基石、第五章中讨论的锁 – Mutex、Condvar、屏障和 RWLock以及我们自己的信号量（在 Rust 中不存在）。根据您的需求，信号量的实现可以改进，我鼓励读者尝试一下。我们还遇到了原子编程的常见问题——内存回收，我们用迈克尔·斯科特队列来讨论这个问题。我们将在下一章深入讨论解决这个问题的方法。

进一步阅读

• 并发对象的公理，莫里斯·赫尔利希和珍妮特·温。赫尔利希和温的这篇论文介绍了线性化的形式定义和形式分析框架。后续工作在此基础上进行了扩展或简化，但鼓励读者至少消化这篇论文的前半部分。

• 分布式算法，南希·林奇。据我所知，林奇的这项工作是首次以教科书形式对分布式算法进行的一般概述。它非常易于理解，林奇的书中的第十三章特别与这次讨论相关。

• 在 C++中，acquire-release 内存顺序语义是传递的吗？，可在softwareengineering.stackexchange.com/questions/253537/in-c-are-acquire-release-memory-order-semantics-transitive找到。内存顺序的影响并不总是清晰的。这个问题在StackExchange上，它影响了本章的写作，是关于在多线程中分割Acquire和Release的后果。鼓励读者在阅读答案之前思考这个问题。

• std::memory_order, CppReference，可在en.cppreference.com/w/cpp/atomic/memory_order找到。Rust 的内存模型是 LLVM 的，而 LLVM 的内存模型又受到 C++内存模型的影响。这篇关于内存排序的讨论特别出色，因为它有示例代码，并且采用了更少语言律师风格的方法来解释排序。

• 使用 C++0x 原子操作实现 Peterson 锁，可在www.justsoftwaresolutions.co.uk/threading/petersons_lock_with_C++0x_atomics.html找到。这篇文章讨论了 Bartosz Milewski 对 Peterson 互斥锁算法的实现，演示了为什么它是错误的，并描述了一个功能性的替代方案。Milewski 是一位知名的 C++专家。这正好说明了原子编程既困难又容易犯细微的错误。

• 互斥锁算法，迈克尔·雷纳尔。雷纳尔的这本书是在 1986 年写的，远在我们讨论的 x86_64 架构之前，并且是在 ARMv1 发布后的第二年。雷纳尔的书仍然很有用，既作为互斥锁算法的历史概述，也适用于同步原语不可用的环境，例如在文件系统中。

• 多种互斥锁实现综述，可在cbloomrants.blogspot.com/2011/07/07-15-11-review-of-many-mutex.html找到。正如标题所示，这篇文章是对许多互斥锁实现的综述，这些实现比 Raynal 的书提供了更现代的背景。一些解释依赖于微软 Windows 的功能，对于这本书主要投资于类 Unix 环境的读者来说可能很受欢迎。

• 降低 Cernan 度量成本，可在blog.troutwine.us/2017/08/31/encheapening-cernan-internal-metrics/找到。在这一章中，我们主要从同步的角度讨论了原子操作。还有许多其他用例。这篇文章讨论了将原子操作应用于为复杂的软件项目提供低成本的自监控。

• 自己动手实现轻量级互斥锁，可在preshing.com/20120226/roll-your-own-lightweight-mutex/找到。Preshing On Programming 网站有一系列优秀的原子操作材料，专注于 C++和微软环境。这篇特定的文章是关于实现互斥锁的，这个主题与本章内容紧密相关，并在评论中有很好的后续讨论。文章讨论了信号量的一种变体，称为 benaphores。

• 简单、快速、实用的非阻塞和阻塞并发队列算法，作者：Maged Michael 和 Michael Scott。本文介绍了本章讨论的 Michael 和 Scott 队列，这也是它最著名的部分。你也许会从上一章中认出他们的带有两个锁的队列，当然是通过 Erlang 虚拟机进行适配的。

• 无锁数据结构：栈的演变，可在kukuruku.co/post/lock-free-data-structures-the-evolution-of-a-stack/找到。这篇帖子讨论了 libcds 对 Trieber 栈的实现，并参考了其他文献领域。读者会注意到之前的 进一步阅读 中介绍了一些相同的文献；寻求不同的观点总是好的。特别鼓励读者调查帖子中引用的 Hendler、Shavit 和 Yerushalmi 的论文。

第七章：原子操作 – 安全地回收内存

在上一章中，我们讨论了 Rust 程序员可用的原子原语，实现了高级同步原语和一些完全由原子组成的数据结构。与使用高级同步原语相比，原子编程的一个关键挑战是内存回收。内存只能安全地释放一次。当我们仅从原子原语构建并发算法时，要只做一次并保持性能是非常具有挑战性的。也就是说，安全地回收内存需要某种形式的同步。但是，随着并发角色的总数增加，同步的成本会超过原子编程的延迟或吞吐量收益。

在本章中，我们将讨论三种解决原子编程内存回收问题的技术——引用计数、危害指针和基于时代的回收。这些方法你从前几章中应该已经熟悉，但在这里我们将深入探讨它们，研究它们的权衡。我们将介绍两个新的库，conc和 crossbeam，分别实现了危害指针和基于时代的回收。到本章结束时，你应该对这三种方法有很好的掌握，并准备好开始编写生产级别的代码。

到本章结束时，我们将：

• 讨论引用计数及其相关的权衡

• 讨论危害指针的内存回收方法

• 使用conc库通过危害指针方法研究了 Treiber 栈

• 讨论基于时代的回收策略

• 对crossbeam_epoch库进行了深入研究

• 使用基于时代的回收方法研究了 Treiber 栈

技术要求

本章需要安装一个可工作的 Rust 环境。验证安装的详细信息请参阅第一章，预备知识 – 计算机架构和 Rust 入门。不需要额外的软件工具。

你可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。本章的源代码位于Chapter07。

内存回收方法

在接下来的讨论中，三种技术将按其速度大致排序，从慢到快，以及它们的难度，从易到难。你不应该气馁——你现在正处于软件工程世界的前沿。欢迎。大胆前行。

引用计数

引用计数内存回收将一块受保护的数据与一个原子计数器关联。每个读取或写入该受保护数据的线程在获取时增加计数器，在释放时减少计数器。减少计数器并发现它为零的线程是最后一个持有数据的线程，它可以标记数据为可回收，或者立即释放它。这应该听起来很熟悉。Rust 标准库附带std::sync::Arc——在第四章 4，同步和发送——Rust 并发的基石，以及第五章 5，锁——Mutex, Condvar, Barriers 和 RWLock中特别提到，以满足这一确切需求。虽然我们讨论了Arc的使用，但我们之前没有讨论其内部结构，因为我们需要先达到第六章 6，原子操作——同步的原始操作，以获得必要的背景知识。现在让我们深入探讨Arc。

Rust 编译器的Arc代码在src/liballoc/arc.rs中。结构定义足够紧凑：

pub struct Arc<T: ?Sized> {
    ptr: Shared<ArcInner<T>>,
    phantom: PhantomData<T>,
}

我们在第三章 3，Rust 内存模型——所有权、引用和操作中遇到了Shared<T>，它是一个具有与*mut X相同特性的指针，除了它不是空指针。创建新的Shared<T>有两个函数，分别是const unsafe fn new_unchecked(ptr: *mut X) -> Self和fn new(ptr: *mut X) -> Option<Self>。在第一个变体中，调用者负责确保指针不是空指针，在第二个变体中，检查指针是否为空。请参阅第三章 3，Rust 内存模型——所有权、引用和操作中的Rc部分以深入了解。我们知道，在Arc<T>中的ptr不是空指针，由于幻数数据字段，T的存储不在Arc<T>中。那会在ArcInner<T>中：

struct ArcInner<T: ?Sized> {
    strong: atomic::AtomicUsize,

    // the value usize::MAX acts as a sentinel for temporarily 
    // "locking" the ability to upgrade weak pointers or 
    // downgrade strong ones; this is used to avoid races
    // in `make_mut` and `get_mut`.
    weak: atomic::AtomicUsize,

    data: T,
}

我们看到两个内部AtomicUsize字段：strong和weak。像Rc一样，Arc<T>允许对内部数据有两种类型的强度引用。弱引用不拥有内部数据，允许Arc<T>在循环中排列而不造成不可能的内存回收情况。强引用拥有内部数据。在这里，我们看到通过Arc<T>::clone() -> Arc<T>创建一个新的强引用：

    fn clone(&self) -> Arc<T> {
        let old_size = self.inner().strong.fetch_add(1, Relaxed);

        if old_size > MAX_REFCOUNT {
            unsafe {
                abort();
            }
        }

        Arc { ptr: self.ptr, phantom: PhantomData }
    }

在这里，我们可以看到，在每次克隆时，使用 relaxed 排序时，ArcInner<T>的strong会增加一个。对此代码块的注释——由于文本简洁性在此省略——断言由于Arc的使用情况，relaxed 排序是足够的。在这里使用 relaxed 排序是可以的，因为对原始引用的了解可以防止其他线程错误地删除对象。这是一个重要的考虑因素。为什么克隆不需要更严格的排序？考虑一个线程A，它克隆了一些Arc<T>并将其传递给另一个线程B，然后，在传递给B之后，立即释放自己的Arc副本。我们可以从检查Arc<T>::new() -> Arc<T>中确定，在创建时，Arc始终有一个强引用和一个弱引用：

    pub fn new(data: T) -> Arc<T> {
        // Start the weak pointer count as 1 which is the weak 
        // pointer that's held by all the strong pointers 
        // (kinda), see std/rc.rs for more info
        let x: Box<_> = box ArcInner {
            strong: atomic::AtomicUsize::new(1),
            weak: atomic::AtomicUsize::new(1),
            data,
        };
        Arc { ptr: Shared::from(Box::into_unique(x)), 
              phantom: PhantomData }
    }

从线程A的角度来看，Arc的克隆由以下操作组成：

clone Arc
    INCR strong, Relaxed
    guard against strong wrap-around
    allocate New Arc
move New Arc into B
drop Arc

从前一章的讨论中我们知道，Release排序不提供因果关系。完全有可能一个敌对的 CPU 会重新排序strong的增加，在New Arc移动到B之后。如果B随后立即释放Arc，我们会遇到麻烦吗？我们需要检查Arc<T>::drop()：

    fn drop(&mut self) {
        if self.inner().strong.fetch_sub(1, Release) != 1 {
            return;
        }

        atomic::fence(Acquire);

        unsafe {
            let ptr = self.ptr.as_ptr();

            ptr::drop_in_place(&mut self.ptr.as_mut().data);

            if self.inner().weak.fetch_sub(1, Release) == 1 {
                atomic::fence(Acquire);
                Heap.dealloc(ptr as *mut u8, Layout::for_value(&*ptr))
            }
        }
    }

这里开始了。atomic::fence(Acquire)对我们来说是新的。std::sync::atomic::fence根据提供的内存排序建立的因果关系，防止内存迁移。栅栏适用于同一线程和其他线程的内存操作。回想一下，Release排序禁止在源代码顺序中向下迁移加载和存储。在这里，我们看到，强引用的加载和存储将禁止向下迁移，但不会在Acquire栅栏之后重新排序。因此，T内部的分配给Arc将不会发生，直到A和B两个线程都已同步并移除了所有强引用。由于建立了因果关系，一个额外的线程C不能在此时通过并增加内部T的强引用，因为A和B都不能在不增加强计数器的情况下给C一个强引用，这会导致A或B的释放提前退出。对于弱引用也有类似的结论。

对Arc进行不可变解引用不会增加强或弱计数：

impl<T: ?Sized> Deref for Arc<T> {
    type Target = T;

    #[inline]
    fn deref(&self) -> &T {
        &self.inner().data
    }
}

因为drop需要一个可变的self，所以在存在有效的&T时，无法释放Arc<T>。获取&mut T更为复杂，这是通过Arc<T>::get_mut(&mut Self) -> Option<&mut T>来实现的。请注意，返回值是一个Option。如果内部T有其他强或弱引用，那么消耗Arc是不安全的。get_mut的实现如下：

    pub fn get_mut(this: &mut Self) -> Option<&mut T> {
        if this.is_unique() {
            // This unsafety is ok because we're guaranteed that the
            // pointer returned is the *only* pointer that will ever
            // be returned to T. Our reference count is guaranteed
            // to be 1 at this point, and we required the Arc itself
            // to be `mut`, so we're returning the only possible 
            // reference to the inner data.
            unsafe {
                Some(&mut this.ptr.as_mut().data)
            }
        } else {
            None
        }
    }

其中is_unique是：

    fn is_unique(&mut self) -> bool {
        if self.inner().weak.compare_exchange(1, usize::MAX, 
                                              Acquire, Relaxed).is_ok() {
            let unique = self.inner().strong.load(Relaxed) == 1;
            self.inner().weak.store(1, Release);
            unique
        } else {
            false
        }
    }

在弱引用上进行的比较和交换操作确保只有一个弱引用存在——意味着唯一性——并在成功时使用 Acquire 排序。这种排序将迫使后续对强引用的检查在代码顺序中发生在弱引用检查之后，并且在释放存储之前。这种确切的技术在我们上一章关于互斥锁的讨论中已经熟悉。

权衡

引用计数作为原子内存回收的方法有很多优点。引用计数的编程模型易于理解，并且一旦可以安全回收，就会立即回收内存。在 Rust 中，由于缺乏双字比较和交换，不使用 Arc<T> 编程引用计数的实现仍然很困难。考虑一个 Treiber 栈，其中引用计数器是栈节点内部的。栈的头部可能被快照，然后由其他线程释放，后续对引用计数器的读取将被迫通过一个无效指针。

以下引用计数的 Treiber 栈存在缺陷：

use std::sync::atomic::{fence, AtomicPtr, AtomicUsize, Ordering};
use std::{mem, ptr};

unsafe impl<T: Send> Send for Stack<T> {}
unsafe impl<T: Send> Sync for Stack<T> {}

struct Node<T> {
    references: AtomicUsize,
    next: *mut Node<T>,
    data: Option<T>,
}

impl<T> Node<T> {
    fn new(t: T) -> Self {
        Node {
            references: AtomicUsize::new(1),
            next: ptr::null_mut(),
            data: Some(t),
        }
    }
}

pub struct Stack<T> {
    head: AtomicPtr<Node<T>>,
}

impl<T> Stack<T> {
    pub fn new() -> Self {
        Stack {
            head: AtomicPtr::default(),
        }
    }

    pub fn pop(&self) -> Option<T> {
        loop {
            let head: *mut Node<T> = self.head.load(Ordering::Relaxed);

            if head.is_null() {
                return None;
            }
            let next: *mut Node<T> = unsafe { (*head).next };

            if self.head.compare_and_swap(head, next, 
            Ordering::Relaxed) == head {
                let mut head: Box<Node<T>> = unsafe {
                    Box::from_raw(head) 
                };
                let data: Option<T> = mem::replace(&mut (*head).data, 
                                                   None);
                unsafe {
                    assert_eq!(
                        (*(*head).next).references.fetch_sub(1, 
                             Ordering::Release),
                        2
                    );
                }
                drop(head);
                return data;
            }
        }
    }

    pub fn push(&self, t: T) -> () {
        let node: *mut Node<T> = Box::into_raw(Box::new(Node::new(t)));
        loop {
            let head = self.head.load(Ordering::Relaxed);
            unsafe {
                (*node).next = head;
            }

            fence(Ordering::Acquire);
            if self.head.compare_and_swap(head, node, 
            Ordering::Release) == head {
                // node is now self.head
                // head is now self.head.next
                if !head.is_null() {
                    unsafe {
                        assert_eq!(1, 
                                   (*head).references.fetch_add(1, 
                                       Ordering::Release)
                        );
                    }
                }
                break;
            }
        }
    }
}

这本书中故意存在的一些（故意）有缺陷的例子之一。鼓励你将本书前面讨论的技术应用到识别和纠正这个实现中的缺陷。这应该很有趣。J.D. Valois 1995 年的论文，《使用比较和交换的无锁链表》，将会有所帮助。此外，强烈鼓励你尝试仅使用 Arc 实现一个 Treiber 栈。

最终，当操作同一引用计数字据的线程数量增加时，引用计数的竞争问题就会出现，那些获取/释放对并不便宜。当预期线程数量相对较低或绝对性能不是关键考虑因素时，引用计数是一个很好的模型。否则，你需要调查以下方法，这些方法也有自己的权衡。

危险指针

我们在上一章中提到了危险指针作为安全内存回收的方法。现在，我们将深入探讨这个概念，并通过对 Redox 项目（crates.io/crates/conc）的更多或更少的可用实现进行考察。我们将检查 conc 作为其父项目 tfs（github.com/redox-os/tfs）的一部分，在 SHA 3e7dcdb0c586d0d8bb3f25bfd948d2f418a4ab10。顺便说一句，如果你不熟悉这个，Redox 是一个基于 Rust 微内核的操作系统。分配器、coreutils 和 netutils 都是推荐阅读的内容。

Conc crate 并没有列出全部内容。你可以在本书的源代码仓库中找到完整的列表。

危险指针是由 Maged Michael——以 Michael 和 Scott 队列闻名——在他的 2004 年著作《Hazard Pointers: Safe Memory Reclamation for Lock-Free Objects》中引入的。在这个上下文中，“危险”是指任何在多个线程参与某些共享数据结构的 rendezvous 中可能发生竞态或 ABA 问题的指针。在上一节的 Treiber 栈中，危险是指 Stack 结构体内部的头指针，而在 Michael 和 Scott 队列中，它是头和尾指针。危险指针将这些危险与由单个写入线程拥有并由任何其他参与数据结构的线程读取的 单写入多读取共享指针 关联起来。

每个参与线程都维护对其自己的危险指针和所有其他参与线程的引用，以及用于协调分配的私有、线程局部列表。Michael 论文第三部分中的算法描述是在高层次上进行的，并且很难通过具体实现来跟踪。而不是在这里重复，我们将检查一个具体的实现，conc。鼓励读者在讨论 conc 之前先阅读 Michael 的论文，但这不是强制性的。

一个危险指针 Treiber 栈

在上一节关于引用计数的部分中引入 Treiber 栈并非无的放矢。我们将通过一个有效回收的 Treiber 栈的视角来检查危险指针和基于纪元的回收。碰巧的是，conc 包含了一个 Treiber 栈，位于 tfs/conc/src/sync/treiber.rs。前言部分大部分是熟悉的：

use std::sync::atomic::{self, AtomicPtr};
use std::marker::PhantomData;
use std::ptr;
use {Guard, add_garbage_box};

Guard 和 add_garbage_box 都是新的，但我们将直接进入正题。Treiber 结构体正如你所想象的那样：

pub struct Treiber<T> {
    /// The head node.
    head: AtomicPtr<Node<T>>,
    /// Make the `Sync` and `Send` (and other OIBITs) transitive.
    _marker: PhantomData<T>,
}

节点也是一样：

struct Node<T> {
    /// The data this node holds.
    item: T,
    /// The next node.
    next: *mut Node<T>,
}

这是我们需要理解 conc::Guard 的地方。与标准库中的 MutexGuard 类似，Guard 在这里存在是为了保护包含的数据不被多次修改。Guard 是 conc 的危险指针接口。让我们详细检查 Guard 并了解危险指针算法。Guard 定义在 tfs/conc/src/guard.rs：

pub struct Guard<T: 'static + ?Sized> {
    /// The inner hazard.
    hazard: hazard::Writer,
    /// The pointer to the protected object.
    pointer: &'static T,
}

在撰写本书时，所有由 Guard 保护的 T 都必须是静态的，但我们将忽略这一点，因为代码库中引用了放宽该限制的愿望。如果你想在项目中立即使用 conc，请注意这一点。就像 MutexGuard 一样，Guard 并不拥有底层数据，而只是保护对它的引用，我们可以看到我们的 Guard 是危险指针的写入端。那么什么是 hazard::Writer？它在 tfs/conc/src/hazard.rs 中定义：

pub struct Writer {
    /// The pointer to the heap-allocated hazard.
    ptr: &'static AtomicPtr<u8>,
}

指向堆分配的危险指针？好吧，让我们退一步。我们知道从算法描述中，必须有与堆存储协调的线程局部存储。我们还知道 Guard 是我们访问危险指针的主要接口。有三个函数用于创建 Guard 的新实例：

• Guard<T>::new<F: FnOnce() -> &'static T>(ptr: F) -> Guard<T>

• Guard<T>::maybe_new<F: FnOnce() -> Option<&'static T>>(ptr: F) -> Option<Guard<T>>

• Guard<T>::try_new<F: FnOnce() -> Result<&'static T, E>>(ptr: F) -> Result<Guard<T>, E>

前两个是通过try_new定义的。让我们剖析一下try_new：

    pub fn try_new<F, E>(ptr: F) -> Result<Guard<T>, E>
    where F: FnOnce() -> Result<&'static T, E> {
        // Increment the number of guards currently being created.
        #[cfg(debug_assertions)]
        CURRENT_CREATING.with(|x| x.set(x.get() + 1));

函数接受FnOnce，其责任是提供一个T的引用或失败。try_new中的第一个调用是CURRENT_CREATING的增加，它是一个thread-local Cell<usize>：

thread_local! {
    /// Number of guards the current thread is creating.
    static CURRENT_CREATING: Cell<usize> = Cell::new(0);
}

我们在第三章中看到了Cell，《Rust 内存模型——所有权、引用和操作，但thread_local!是新的。这个宏将一个或多个静态值包装到std::thread::LocalKey中，这是 Rust 对线程局部存储的实现。具体的实现因平台而异，但基本思想是一致的：值将作为静态全局变量，但将限制在单个线程中。这样，我们可以像使用全局变量一样编程，而无需管理线程之间的协调。一旦CURRENT_CREATING增加：

        // Get a hazard in blocked state.
        let hazard = local::get_hazard();

local::get_hazard函数定义在tfs/conc/src/local.rs中：

pub fn get_hazard() -> hazard::Writer {
    if STATE.state() == thread::LocalKeyState::Destroyed {
        // The state was deinitialized, so we must rely on the
        // global state for creating new hazards.
        global::create_hazard()
    } else {
        STATE.with(|s| s.borrow_mut().get_hazard())
    }
}

此函数中引用的STATE是：

thread_local! {
    /// The state of this thread.
    static STATE: RefCell<State> = RefCell::new(State::default());
}

State的定义如下：

#[derive(Default)]
struct State {
    garbage: Vec<Garbage>,
    available_hazards: Vec<hazard::Writer>,
    available_hazards_free_before: usize,
}

字段垃圾维护了一个尚未移动到全局状态的Garbage列表——关于这一点，我们稍后再谈——用于回收。Garbage是一个指向字节的指针，以及一个指向字节的函数指针，称为dtor，用于析构函数。内存回收方案必须能够释放，无论底层类型如何。常见的做法，也是Garbage采取的做法，是在类型信息可用时构建一个单态化析构函数，否则在字节缓冲区上工作。我们鼓励你自己浏览Garbage的实现，但主要的技巧是Box::from_raw(ptr as *mut u8 as *mut T)，这是我们在这本书中反复看到的。

available_hazards字段存储了之前分配但尚未使用的分配器危害写入器。实现将其作为缓存以避免分配器抖动。我们可以在local::State::get_hazard中看到这一点：

    fn get_hazard(&mut self) -> hazard::Writer {
        // Check if there is hazards in the cache.
        if let Some(hazard) = self.available_hazards.pop() {
            // There is; we don't need to create a new hazard.
            //
            // Since the hazard popped from the cache is not 
            // blocked, we must block the hazard to satisfy 
            // the requirements of this function.
            hazard.block();
            hazard
        } else {
            // There is not; we must create a new hazard.
            global::create_hazard()
        }
    }

最后一个字段available_hazards_free_before存储了在释放底层类型之前的释放状态中的危害。我们稍后会进一步讨论这个问题。危害处于四种状态之一：空闲、已死亡、阻塞或保护。一个已死亡的危害可以安全地释放，包括受保护的内存。一个已死亡的危害不应该被读取。一个空闲的危害没有保护任何东西，可以重用。一个阻塞的危害正被其他线程使用，并且会导致危害读取停滞。一个保护危害正在保护一些内存。现在，回到local::get_hazard的这个分支：

    if STATE.state() == thread::LocalKeyState::Destroyed {
        // The state was deinitialized, so we must rely on the 
        // global state for creating new hazards.
        global::create_hazard()
    } else {

global::create_hazard是什么？此模块是tfs/conc/src/global.rs，函数如下：

pub fn create_hazard() -> hazard::Writer {
    STATE.create_hazard()
}

变量名令人困惑。这个 STATE 不是线程本地的 STATE，而是一个全局作用域的 STATE：

lazy_static! {
    /// The global state.
    ///
    /// This state is shared between all the threads.
    static ref STATE: State = State::new();
}

让我们深入探讨：

struct State {
    /// The message-passing channel.
    chan: mpsc::Sender<Message>,
    /// The garbo part of the state.
    garbo: Mutex<Garbo>,
}

全局 STATE 是 Message 的 mpsc Sender 和一个互斥锁保护的 Garbo。Message 是一个简单的枚举：

enum Message {
    /// Add new garbage.
    Garbage(Vec<Garbage>),
    /// Add a new hazard.
    NewHazard(hazard::Reader),
}

Garbo 是我们将直接探讨的内容。现在只需说，Garbo 作为此实现的全球垃圾回收器。全局状态设置了一个通道，维护全局状态中的发送方，并将接收方喂入 Garbo：

impl State {
    /// Initialize a new state.
    fn new() -> State {
        // Create the message-passing channel.
        let (send, recv) = mpsc::channel();

        // Construct the state from the two halfs of the channel.
        State {
            chan: send,
            garbo: Mutex::new(Garbo {
                chan: recv,
                garbage: Vec::new(),
                hazards: Vec::new(),
            })
        }
    }

创建一个新的全局风险并不需要太多：

    fn create_hazard(&self) -> hazard::Writer {
        // Create the hazard.
        let (writer, reader) = hazard::create();
        // Communicate the new hazard to the global state 
        // through the channel.
        self.chan.send(Message::NewHazard(reader));
        // Return the other half of the hazard.
        writer
    }

这通过 hazard::create() 建立了一个新的风险，并将读取器侧向下传递到 Garbo，将写入器侧返回到 local::get_hazard()。虽然 writer 和 reader 的名字暗示风险本身是一个 MPSC，但这并不正确。风险模块是 tfs/conc/src/hazard.rs，创建如下：

pub fn create() -> (Writer, Reader) {
    // Allocate the hazard on the heap.
    let ptr = unsafe {
        &*Box::into_raw(Box::new(AtomicPtr::new(
                        &BLOCKED as *const u8 as *mut u8)))
    };

    // Construct the values.
    (Writer {
        ptr: ptr,
    }, Reader {
        ptr: ptr,
    })
}

好吧，看看这个。我们这里有两个结构体，Writer 和 Reader，它们各自存储指向堆分配的原子指针的可变字节指针的相同原始指针。呼！我们之前已经看到过这个技巧，但这里特殊的是利用类型系统为同一块原始内存提供不同的读写接口。

那么 Garbo 呢？它在全局模块中定义，定义为：

struct Garbo {
    /// The channel of messages.
    chan: mpsc::Receiver<Message>,
    /// The to-be-destroyed garbage.
    garbage: Vec<Garbage>,
    /// The current hazards.
    hazards: Vec<hazard::Reader>,
}

Garbo 定义了一个 gc 函数，该函数从其通道读取所有 Messages，将垃圾存储到垃圾字段，将自由风险存储到风险字段。已死亡的风险被销毁，释放其存储空间，因为其他持有者已经保证已经挂起。受保护的风险也进入风险字段，这些字段将在下一次调用 gc 时被扫描。当线程调用 global::tick() 或调用 global::try_gc() 时，有时会执行垃圾回收。每当调用 local::add_garbage 时，就会执行一个 tick，这是 whatconc::add_garbage_box 调用的。

我们在本节的开头首次遇到了 add_barbage_box。每当一个线程将一个节点标记为垃圾时，它掷骰子，并可能成为负责在所有线程的风险指针内存上执行全局垃圾回收的责任人。

现在我们已经了解了内存回收的工作原理，剩下要理解的是风险指针如何保护内存免受读写。让我们一次性完成 guard::try_new：

        // This fence is necessary for ensuring that `hazard` does not
        // get reordered to after `ptr` has run.
        // TODO: Is this fence even necessary?
        atomic::fence(atomic::Ordering::SeqCst);

        // Right here, any garbage collection is blocked, due to the
        // hazard above. This ensures that between the potential 
        // read in `ptr` and it being protected by the hazard, there
        // will be no premature free.

        // Evaluate the pointer through the closure.
        let res = ptr();

        // Decrement the number of guards currently being created.
        #[cfg(debug_assertions)]
        CURRENT_CREATING.with(|x| x.set(x.get() - 1));

        match res {
            Ok(ptr) => {
                // Now that we have the pointer, we can protect it by 
                // the hazard, unblocking a pending garbage collection
                // if it exists.
                hazard.protect(ptr as *const T as *const u8);

                Ok(Guard {
                    hazard: hazard,
                    pointer: ptr,
                })
            },
            Err(err) => {
                // Set the hazard to free to ensure that the hazard 
                // doesn't remain blocking.
                hazard.free();

                Err(err)
            }
        }
    }

我们可以看到，conc 的作者插入了一个他们质疑的顺序一致性栅栏。Michael 提出的模型不需要顺序一致性，我相信这个栅栏是不必要的，因为它会显著降低性能。这里要注意的关键点是 hazard::protect 调用和 'hazard::free'。这两个调用都是 hazard::Writer 的部分，前者将内部指针设置为提供给它的字节指针，后者将危害标记为自由。这两种状态都与垃圾回收器交互，正如我们所见。剩下的部分与 hardard::Reader::get 有关，这是用来检索危害状态的函数。这里就是它：

impl Reader {
    /// Get the state of the hazard.
    ///
    /// It will spin until the hazard is no longer in a blocked state, 
    /// unless it is in debug mode, where it will panic given enough
    /// spins.
    pub fn get(&self) -> State {
        // In debug mode, we count the number of spins. In release 
        // mode, this should be trivially optimized out.
        let mut spins = 0;

        // Spin until not blocked.
        loop {
            let ptr = self.ptr.load(atomic::Ordering::Acquire) 
                          as *const u8;

            // Blocked means that the hazard is blocked by another 
            // thread, and we must loop until it assumes another 
            // state.
            if ptr == &BLOCKED {
                // Increment the number of spins.
                spins += 1;
                debug_assert!(spins < 100_000_000, "\
                    Hazard blocked for 100 millions rounds. Panicking 
                    as chances are that it will \
                    never get unblocked.\
                ");

                continue;
            } else if ptr == &FREE {
                return State::Free;
            } else if ptr == &DEAD {
                return State::Dead;
            } else {
                return State::Protect(ptr);
            }

只有当危害被阻塞时，状态的获取才会旋转，直到它死亡、自由或仅仅被保护。什么阻塞了危害？回想一下，它们是在阻塞状态下创建的。通过在阻塞状态下创建危害，我们无法在未完全初始化的指针上执行垃圾回收——这是我们参考计数实现中遇到的问题——也无法从部分初始化的危害指针中读取。只有当指针移动到保护状态后，读取才能继续。

就这样——垃圾回收和原子隔离。

让我们一路追溯到栈，看看其推送实现：

    pub fn push(&self, item: T)
    where T: 'static {
        let mut snapshot = Guard::maybe_new(|| unsafe {
            self.head.load(atomic::Ordering::Relaxed).as_ref()
        });

        let mut node = Box::into_raw(Box::new(Node {
            item: item,
            next: ptr::null_mut(),
        }));

        loop {
            let next = snapshot.map_or(ptr::null_mut(), 
                                       |x| x.as_ptr() as *mut _);
            unsafe { (*node).next = next; }

            match Guard::maybe_new(|| unsafe {
                self.head.compare_and_swap(next, node, 
                    atomic::Ordering::Release).as_ref()
            }) {
                Some(ref new) if new.as_ptr() == next => break,
                None if next.is_null() => break,
                // If it fails, we will retry the CAS with updated 
                // values.
                new => snapshot = new,
            }
        }
    }

在函数顶部，实现将头节点的危害指针加载到快照中。Guard::as_ptr(&self) -> *const T 在每次调用时检索危害的当前指针，随着底层数据的向前移动而适应。节点是包含 item: T 的已分配和原始指针 Node。循环的其余部分与我们所见到的其他此类数据结构的比较和交换相同，只是用危害 Guard 而不是原始 AtomicPtrs 或类似的东西。编程模型非常直接，就像 pop 一样：

    pub fn pop(&self) -> Option<Guard<T>> {
        let mut snapshot = Guard::maybe_new(|| unsafe {
            self.head.load(atomic::Ordering::Acquire).as_ref()
        });

        while let Some(old) = snapshot {
            snapshot = Guard::maybe_new(|| unsafe {
                self.head.compare_and_swap(
                    old.as_ptr() as *mut _,
                    old.next as *mut Node<T>,
                    atomic::Ordering::Release,
                ).as_ref()
            });

            if let Some(ref new) = snapshot {
                if new.as_ptr() == old.as_ptr() {
                    unsafe { add_garbage_box(old.as_ptr()); }
                    return Some(old.map(|x| &x.item));
                }
            } else {
                break;
            }
        }

        None
    }

注意，当旧节点从栈中移除时，会对其调用 add_garbage_box，将节点添加到稍后进行垃圾回收。此外，通过检查我们知道，这个“稍后”可能正好是调用的那一刻，这取决于运气。

夜间危害

不幸的是，conc 依赖于 Rust 编译器的一个不稳定特性，并且无法与最近的 rustc 编译。conc 以及其父项目 TFS 的最后一次更新是在 2017 年 8 月。我们将不得不回到那个时期的夜间 rustc。如果你遵循了 第一章 中概述的说明，预备知识 – 计算机架构和 Rust 入门，并且使用 rustup，那么只需简单地使用 rustup 默认的 nightly-2017-08-17。当你玩完 conc 后，别忘了切换回更现代的 Rust。

练习危害指针 Treiber 栈

让我们用 conc、Treiber 栈来测试这个方法，以了解其性能。对我们来说，关键的兴趣领域包括：

• 每秒的推入/弹出周期

• 内存行为，最高水位线，等等

• 缓存行为

我们将在 x86 和 ARM 上运行我们的程序，就像前几章所做的那样。在此进行之前需要注意的一点是，至少在版本 0.5 中，conc 需要使用夜间频道进行编译。如果您在书中跳来跳去，请阅读本节之前的部分以获取完整详情。

因为我们必须运行在旧版本的夜间版本上，所以我们不得不将静态 AtomicUsize 放入 lazy_static! 中，这是一种你会在旧 Rust 代码中看到但通常不会在这本书中看到的技巧。考虑到这一点，以下是我们练习程序：

extern crate conc;
#[macro_use]
extern crate lazy_static;
extern crate num_cpus;
extern crate quantiles;

use conc::sync::Treiber;
use quantiles::ckms::CKMS;
use std::sync::Arc;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::{thread, time};

lazy_static! {
    static ref WORKERS: AtomicUsize = AtomicUsize::new(0);
    static ref COUNT: AtomicUsize = AtomicUsize::new(0);
}
static MAX_I: u32 = 67_108_864; // 2 ** 26

fn main() {
    let stk: Arc<Treiber<(u64, u64, u64)>> = Arc::new(Treiber::new());

    let mut jhs = Vec::new();

    let cpus = num_cpus::get();
    WORKERS.store(cpus, Ordering::Release);

    for _ in 0..cpus {
        let stk = Arc::clone(&stk);
        jhs.push(thread::spawn(move || {
            for i in 0..MAX_I {
                stk.push((i as u64, i as u64, i as u64));
                stk.pop();
                COUNT.fetch_add(1, Ordering::Relaxed);
            }
            WORKERS.fetch_sub(1, Ordering::Relaxed)
        }))
    }

    let one_second = time::Duration::from_millis(1_000);
    let mut iter = 0;
    let mut cycles: CKMS<u32> = CKMS::new(0.001);
    while WORKERS.load(Ordering::Relaxed) != 0 {
        let count = COUNT.swap(0, Ordering::Relaxed);
        cycles.insert((count / cpus) as u32);
        println!(
            "CYCLES PER SECOND({}):\n  25th: \
            {}\n  50th: {}\n  75th: \
            {}\n  90th: {}\n  max:  {}\n",
            iter,
            cycles.query(0.25).unwrap().1,
            cycles.query(0.50).unwrap().1,
            cycles.query(0.75).unwrap().1,
            cycles.query(0.90).unwrap().1,
            cycles.query(1.0).unwrap().1
        );
        thread::sleep(one_second);
        iter += 1;
    }

    for jh in jhs {
        jh.join().unwrap();
    }
}

我们有与目标机器中 CPU 总数相等的多个工作线程，每个线程执行一次推入然后立即弹出栈的操作。一个 COUNT 被保持，主线程大约每秒交换那个值到 0，并将该值投入到一个分位数估计结构中——在 第四章 中更详细地讨论了这一点，同步和发送——Rust 并发的基础——并打印出每秒记录的周期摘要，按 CPU 数量进行缩放。工作线程将周期推进到 MAX_I，这个值任意设置为 2**26 的小值。当工作线程完成周期后，它减少 WORKERS 并退出。一旦 WORKERS 达到零，主循环也退出。

在我的 x86 机器上，这个程序退出大约需要 58 秒，输出如下：

CYCLES PER SECOND(0):
  25th: 0
  50th: 0
  75th: 0
  90th: 0
  max:  0

CYCLES PER SECOND(1):
  25th: 0
  50th: 0
  75th: 1124493
  90th: 1124493
  max:  1124493

...

CYCLES PER SECOND(56):
  25th: 1139055
  50th: 1141656
  75th: 1143781
  90th: 1144324
  max:  1145284

CYCLES PER SECOND(57):
  25th: 1139097
  50th: 1141656
  75th: 1143792
  90th: 1144324
  max:  1145284
CYCLES PER SECOND(58):
  25th: 1139097
  50th: 1141809
  75th: 1143792
  90th: 1144398
  max:  1152384

x86 的性能运行如下：

> perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses target/release/conc_stack > /dev/null

 Performance counter stats for 'target/release/conc_stack':

     230503.932161      task-clock (msec)         #    3.906 CPUs utilized
               943      context-switches          #    0.004 K/sec
             9,140      page-faults               #    0.040 K/sec
   665,734,124,408      cycles                    #    2.888 GHz 
   529,230,473,047      instructions              #    0.79  insn per cycle 
    99,146,219,517      branches                  #  430.128 M/sec 
     1,140,398,326      branch-misses             #    1.15% of all branches
    12,759,284,944      cache-references          #   55.354 M/sec
       124,487,844      cache-misses              #    0.976 % of all cache refs

      59.006842741 seconds time elapsed

这个程序的内存分配行为也非常有利。

在我的 ARM 机器上，程序运行到完成大约需要 460 秒，输出如下：

CYCLES PER SECOND(0):
  25th: 0
  50th: 0
  75th: 0
  90th: 0
  max:  0
CYCLES PER SECOND(1):
  25th: 0
  50th: 0
  75th: 150477
  90th: 150477
  max:  150477

...

CYCLES PER SECOND(462):
  25th: 137736
  50th: 150371
  75th: 150928
  90th: 151129
  max:  151381

CYCLES PER SECOND(463):
  25th: 137721
  50th: 150370
  75th: 150928
  90th: 151129
  max:  151381

这比 x86 机器慢大约 7.5 倍，尽管两台机器的核心数量相同。x86 机器的时钟和内存总线比我的 ARM 快：

> perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache
-references,cache-misses target/release/conc_stack > /dev/null

 Performance counter stats for 'target/release/conc_stack':

    1882745.172714      task-clock (msec)         #    3.955 CPUs utilized
                 0      context-switches          #    0.000 K/sec
             3,212      page-faults               #    0.002 K/sec
 2,109,536,434,019      cycles                    #    1.120 GHz
 1,457,344,087,067      instructions              #    0.69  insn per cycle
   264,210,403,390      branches                  #  140.333 M/sec
    36,052,283,984      branch-misses             #   13.65% of all branches
   642,854,259,575      cache-references          #  341.445 M/sec
     2,401,725,425      cache-misses              #    0.374 % of all cache refs

     476.095973090 seconds time elapsed

ARM 上的分支缺失率比 x86 高 12%，这是一个有趣的结果。

在继续之前，请记住执行 rustup default stable。

折衷

假设 conc 已经与现代化的 Rust 同步，您希望在哪里应用它？好吧，让我们将其与引用计数进行比较。在引用计数的数据结构中，每次读取和修改都需要操作原子值，这意味着线程之间需要一定程度的同步，这会影响性能。在危险指针的情况下也存在类似的情况，尽管程度较小。正如我们所见，危险指针需要同步，但通过它读取除危险指针之外的内容，将会以机器速度进行。这比引用计数有显著的改进。此外，我们知道危险指针方法确实会积累垃圾——而 conc 的实现是通过一个特别巧妙的方法完成的——但无论更新危险结构的频率如何，这种垃圾的大小都是有限的。垃圾回收的成本被放在一个线程上，这可能导致某些操作的高延迟峰值，但同时也从批量操作调用分配器中受益。这与引用计数方法不同，在引用计数方法中，每个线程都负责在内存死亡时立即释放死亡内存，保持操作成本开销相似但高于基线，并且在每个操作上产生，而没有批量积累释放操作的好处。随着线程数量的增加，危险指针方法会面临挑战：回想一下，所需的危险数量会随着线程数量的线性增长而增长，但也要考虑到线程数量的增加会增加任何结构的遍历成本。此外，虽然许多结构都有容易识别的危险点，但这并不普遍适用。对于 b 树，您将把危险指针放在哪里？

总结来说——当您需要处理的危险内存引用相对较少，并且需要有限制的垃圾回收，无论结构上的负载如何时，危险指针是一个非常好的选择。基于危险的内存回收并不具备基于时代的回收的原始速度，但在所有情况下有限的内存使用都是难以放弃的。

基于时代的回收

在上一章中，我们提到了基于纪元的内存回收。现在，我们将深入探讨这一概念，并通过对 crossbeam 项目（github.com/crossbeam-rs）的现成实现进行考察。一些 conc 的开发者与 crossbeam 有交集，但为了追求 Rust 中的低级原子编程的通用框架，crossbeam 上做了更多的工作。开发者们指出，他们计划支持其他内存管理方案，例如危害指针（HP）和静默状态基于回收（QSBR）。该包被重新导出为纪元模块。本书的未来版本可能只会涵盖 crossbeam，并简单地讨论其中嵌入的各种内存回收技术。本节我们将讨论的特定包是 crossbeam-epoch，其 SHA 值为 3179e799f384816a0a9f2a3da82a147850e14d38。这与项目的 0.4.1 版本相一致。

这里讨论的 crossbeam 包并不完整。您可以在本书的源代码库中找到完整的列表。

基于纪元的内存回收是由 Keir Fraser 在他的 2004 年博士论文《实用锁自由》中引入的。Fraser 的工作建立在之前的 limbo 列表方法之上，其中垃圾被放置在全局列表中，并通过周期性扫描回收，当可以证明垃圾不再被引用时。确切的机制因作者而异，但 limbo 列表有一些严重的正确性和性能缺点。Fraser 的改进是将 limbo 列表分为三个纪元：当前纪元、中间纪元和可以回收垃圾的纪元。每个参与线程在启动时负责观察当前纪元，将其垃圾添加到当前纪元，并在其操作完成后尝试增加纪元计数。最后一个完成操作的线程将成功增加纪元，并负责在最终纪元上执行垃圾回收。当线程独立移动到纪元时，需要三个总纪元：一个位于纪元 n 的线程可能仍然持有来自 n-1 的引用，但不能持有来自 n-2 的引用，因此只有 n-2 是安全的可以回收。Fraser 的论文相当长——毕竟，这是获得博士学位的足够工作量——但 Hart 等人 2007 年的论文《无锁同步的内存回收性能》强烈推荐给时间紧迫的读者。

基于纪元的 Treiber 栈

我们在本章早期检查了基于引用计数和危害指针的 Treiber 栈，本节也将采用这种方法。幸运的是，crossbeam 还提供了一个 Treiber 栈实现，位于 crossbeam-rs/crossbeam 项目中，我们将在 SHA 值为 89bd6857cd701bff54f7a8bf47ccaa38d5022bfb 的位置进行考察，这是 crossbeam::sync::TreiberStack 的来源，位于 src/sync/treiber_stack.rs。前言部分几乎立即就很有趣：

use std::sync::atomic::Ordering::{Acquire, Relaxed, Release};
use std::ptr;

use epoch::{self, Atomic, Owned};

比如，epoch::Atomic和epoch::Owned是什么意思？嗯，我们在这里会探讨这些。与探索 conc 实现的深度优先方法不同，我们将采取广度优先的方法，或多或少。原因在于 crossbeam-epoch 很复杂——很容易迷路。抛开对epoch::Atomic的某种未知性质，TreiberStack和Node结构体与我们看到的其他实现类似：

#[derive(Debug)]
pub struct TreiberStack<T> {
    head: Atomic<Node<T>>,
}

#[derive(Debug)]
struct Node<T> {
    data: T,
    next: Atomic<Node<T>>,
}

以及创建一个新的栈：

impl<T> TreiberStack<T> {
    /// Create a new, empty stack.
    pub fn new() -> TreiberStack<T> {
        TreiberStack {
            head: Atomic::null(),
        }
    }

推入一个新元素看起来也很熟悉：

    pub fn push(&self, t: T) {
        let mut n = Owned::new(Node {
            data: t,
            next: Atomic::null(),
        });
        let guard = epoch::pin();
        loop {
            let head = self.head.load(Relaxed, &guard);
            n.next.store(head, Relaxed);
            match self.head.compare_and_set(head, n, Release, &guard) {
                Ok(_) => break,
                Err(e) => n = e.new,
            }
        }
    }

除了，epoch::pin()是什么意思？这个函数pins当前线程，返回一个crossbeam_epoch::Guard。就像我们在书中看到的之前的守卫一样，crossbeam_epoch 的Guard保护一个资源。在这种情况下，守卫保护线程的固定性质。一旦守卫释放，线程就不再固定。好吧，太好了，那么线程固定意味着什么呢？回想一下，基于 epoch 的回收是通过线程进入一个 epoch，对内存进行一些操作，然后在完成与内存的交互后可能增加 epoch 来工作的。这个过程在 crossbeam 中通过固定来实现。持有Guard意味着已经进入了一个安全的 epoch——线程能够进行堆分配并获取其栈引用。然而，任何旧的堆分配和栈引用都是不安全的。这里没有魔法。这就是Atomic和Owned出现的地方。它们是标准库中的AtomicPtr和Box的类似物，只不过对它们的操作需要crossbeam_epoch::Guard的引用。我们在第四章中看到了这种技术，当时在讨论 hopper 时，使用类型系统确保通过要求调用者传递某种类型的守卫来安全地执行可能不安全的线程操作。程序员错误可能会通过使用AtomicPtr、Box或任何非 epoch 未受保护的内存访问而悄悄出现，但这些通常会突出显示。

让我们看看从栈中弹出元素的情况，我们知道标记内存为可删除的安全操作将必须发生：

    pub fn try_pop(&self) -> Option<T> {
        let guard = epoch::pin();
        loop {
            let head_shared = self.head.load(Acquire, &guard);
            match unsafe { head_shared.as_ref() } {
                Some(head) => {
                    let next = head.next.load(Relaxed, &guard);
                    if self.head
                        .compare_and_set(head_shared, next, Release, 
                         &guard)
                        .is_ok()
                    {
                        unsafe {
                            guard.defer(move || 
                            head_shared.into_owned());
                            return Some(ptr::read(&(*head).data));
                        }
                    }
                }
                None => return None,
            }
        }
    }

需要注意的关键点是通过对 Atomic 进行加载创建head_shared，然后是常规的比较和设置操作，以及以下内容：

    guard.defer(move || head_shared.into_owned());
    return Some(ptr::read(&(*head).data));

head_shared被移动到一个闭包中，转换，然后这个闭包被传递到Guard尚未检查的 defer 函数中。但是，头被解引用，并从中读取数据并返回。如果没有一些特殊的技巧，这是危险的。我们需要了解更多信息。

crossbeam_epoch::Atomic

让我们深入探讨我们的数据持有者Atomic。这个结构来自 crossbeam_epoch 库，其实现位于src/atomic.rs：

pub struct Atomic<T> {
    data: AtomicUsize,
    _marker: PhantomData<*mut T>,
}

unsafe impl<T: Send + Sync> Send for Atomic<T> {}
unsafe impl<T: Send + Sync> Sync for Atomic<T> {}

表示有点奇怪：为什么不直接是 data: *mut T？Crossbeam 的开发者在这里做了一些巧妙的事情。在现代机器上，指针内部有相当多的空间来存储信息，在最低有效位。考虑一下，如果我们只指向对齐的数据，内存地址在 32 位系统上将是 4 的倍数，在 64 位系统上是 8 的倍数。这会在 32 位系统上留下指针末尾的两个零位，在 64 位系统上留下三个零位。这些位可以存储信息，称为标记。Atomic 可以被标记的事实将发挥作用。但是，Rust 不允许我们像其他系统编程语言那样操作指针。为此，并且因为 usize 是机器字的大小，crossbeam 将其 *mut T 存储为 usize，允许对指针进行标记。空 Atomics 等价于指向零的标记指针：

    pub fn null() -> Atomic<T> {
        Self {
            data: ATOMIC_USIZE_INIT,
            _marker: PhantomData,
        }
    }

新的 Atomic 通过将 T 传递给 Owned—这是我们之前看到的，然后从那个 Owned 转换而来来创建：

    pub fn new(value: T) -> Atomic<T> {
        Self::from(Owned::new(value))
    }

Owned 盒子 T，执行堆分配：

impl<T> Owned<T> {
    pub fn new(value: T) -> Owned<T> {
        Self::from(Box::new(value))
    }

然后将那个盒转换为 *mut T：

impl<T> From<Box<T>> for Owned<T> {
    fn from(b: Box<T>) -> Self {
        unsafe { Self::from_raw(Box::into_raw(b)) }
    }
}

然后将它转换为一个标记指针：

pub unsafe fn from_raw(raw: *mut T) -> Owned<T> {
    ensure_aligned(raw);
    Self::from_data(raw as usize)
}

这有点远，但那告诉我们 Atomic 在数据表示方面与 AtomicPtr 没有区别，只是指针本身被标记了。

现在，关于原子指针的常规操作，如加载等，又是如何不同的？在 Atomic 中，这些有什么区别？好吧，首先，我们知道每个调用都必须传递一个 epoch Guard，但还有其他重要的区别。这是 Atomic::load：

    pub fn load<'g>(&self, ord: Ordering, _: &'g Guard) 
        -> Shared<'g, T> 
    {
        unsafe { Shared::from_data(self.data.load(ord)) }
    }

我们可以看到 self.data.load(ord)，所以底层原子加载是按预期进行的。但是，什么是 Shared？

pub struct Shared<'g, T: 'g> {
    data: usize,
    _marker: PhantomData<(&'g (), *const T)>,
}

它是对 Atomic 的引用，其中嵌入了 Guard 的引用。只要 Shared 存在，对它进行内存操作的安全 Guard 也会存在，并且，重要的是，不能在 Shared 被丢弃之前停止存在。Atomic::compare_and_set 引入了一些额外的特质：

    pub fn compare_and_set<'g, O, P>(
        &self,
        current: Shared<T>,
        new: P,
        ord: O,
        _: &'g Guard,
    ) -> Result<Shared<'g, T>, CompareAndSetError<'g, T, P>>
    where
        O: CompareAndSetOrdering,
        P: Pointer<T>,
    {
        let new = new.into_data();
        self.data
            .compare_exchange(current.into_data(), new,
                              ord.success(), ord.failure())
            .map(|_| unsafe { Shared::from_data(new) })
            .map_err(|current| unsafe {
                CompareAndSetError {
                    current: Shared::from_data(current),
                    new: P::from_data(new),
                }
            })
    }

注意到 compare_and_set 是基于 compare_exchange 定义的。这个 CAS 原语相当于比较交换，但那个交换允许失败具有更宽松的语义，在某些平台上提供性能提升。比较和设置的实现需要理解哪种成功 Ordering 与哪种失败 Ordering 匹配，从而产生 CompareAndSetOrdering：

pub trait CompareAndSetOrdering {
    /// The ordering of the operation when it succeeds.
    fn success(&self) -> Ordering;

    /// The ordering of the operation when it fails.
    ///
    /// The failure ordering can't be `Release` or `AcqRel` and must be 
    /// equivalent or weaker than the success ordering.
    fn failure(&self) -> Ordering;
}

impl CompareAndSetOrdering for Ordering {
    #[inline]
    fn success(&self) -> Ordering {
        *self
    }

    #[inline]
    fn failure(&self) -> Ordering {
        strongest_failure_ordering(*self)
    }
}

在 strongest_failure_ordering 是：

fn strongest_failure_ordering(ord: Ordering) -> Ordering {
    use self::Ordering::*;
    match ord {
        Relaxed | Release => Relaxed,
        Acquire | AcqRel => Acquire,
        _ => SeqCst,
    }
}

最后一个新特质是 Pointer，这是一个提供对 Owned 和 Shared 上的函数的小工具特质：

pub trait Pointer<T> {
    /// Returns the machine representation of the pointer.
    fn into_data(self) -> usize;

    /// Returns a new pointer pointing to the tagged pointer `data`.
    unsafe fn from_data(data: usize) -> Self;
}

crossbeam_epoch::Guard::defer

现在，再次，以下在 TreiberStack::try_pop 中的操作是如何安全进行的？

guard.defer(move || head_shared.into_owned());
return Some(ptr::read(&(*head).data));

我们现在需要探索的是 defer，它在 crossbeam-epoch 的 src/guard.rs 中：

    pub unsafe fn defer<F, R>(&self, f: F)
    where
        F: FnOnce() -> R,
    {
        let garbage = Garbage::new(|| drop(f()));

        if let Some(local) = self.local.as_ref() {
            local.defer(garbage, self);
        }
    }

我们需要理解 Garbage。它在 src/garbage.rs 中定义为：

pub struct Garbage {
    func: Deferred,
}

unsafe impl Sync for Garbage {}
unsafe impl Send for Garbage {}

Garbage 的实现非常简短：

impl Garbage {
    /// Make a closure that will later be called.
    pub fn new<F: FnOnce()>(f: F) -> Self {
        Garbage { func: Deferred::new(move || f()) }
    }
}

impl Drop for Garbage {
    fn drop(&mut self) {
        self.func.call();
    }
}

Deferred 是一个小的结构，它包装了 FnOnce()，根据大小允许将其存储在行内或堆上。鼓励你自己检查实现，但基本思想是在堆分配的结构中保持 FnOnce 的相同属性，该结构在 Garbage 丢弃实现中找到用途。什么丢弃 Garbage？这正是以下内容发挥作用的地方：

        if let Some(local) = self.local.as_ref() {
            local.defer(garbage, self);
        }
    }

Guard 的 self.local 是 *const Local，这是一个在 crossbeam 文档中被称为垃圾回收参与者的结构。我们需要了解这个 Local 是在哪里以及如何被创建的。首先让我们来理解一下 Guard 的内部结构：

pub struct Guard {
    pub(crate) local: *const Local,
}

Guard 是一个指向 Local 的常量指针的包装器。我们知道 Guard 的实例是由 crossbeam_epoch::pin 创建的，该函数定义在 src/default.rs 中：

pub fn pin() -> Guard {
    HANDLE.with(|handle| handle.pin())
}

HANDLE 是一个线程局部静态变量：

thread_local! {
    /// The per-thread participant for the default garbage collector.
    static HANDLE: Handle = COLLECTOR.register();
}

COLLECTOR 是一个静态的全局变量：

lazy_static! {
    /// The global data for the default garbage collector.
    static ref COLLECTOR: Collector = Collector::new();
}

这一次同时出现了很多新事物。固定是一个非平凡的活动！正如其名称所暗示的以及其文档所述，COLLECTOR 是 crossbeam-epoch 的全局垃圾收集器的入口点，称为 Global。Collector 定义在 src/collector.rs 中，并且有一个非常简短的实现：

pub struct Collector {
    pub(crate) global: Arc<Global>,
}

unsafe impl Send for Collector {}
unsafe impl Sync for Collector {}

impl Collector {
    /// Creates a new collector.
    pub fn new() -> Self {
        Collector { global: Arc::new(Global::new()) }
    }

    /// Registers a new handle for the collector.
    pub fn register(&self) -> Handle {
        Local::register(self)
    }
}

我们知道 Collector 是一个全局静态变量，这意味着 Global::new() 只会调用一次。Global 定义在 src/internal.rs 中，是全局垃圾收集器的数据存储库：

pub struct Global {
    /// The intrusive linked list of `Local`s.
    locals: List<Local>,

    /// The global queue of bags of deferred functions.
    queue: Queue<(Epoch, Bag)>,

    /// The global epoch.
    pub(crate) epoch: CachePadded<AtomicEpoch>,
}

列表是一个侵入式列表，我们在 Local 的定义中看到了对其的引用。侵入式列表是一个链表，其中列表中下一个节点的指针存储在数据本身中，即 Local 的 entry: Entry 字段。侵入式列表并不常见，但当你关心小内存分配或需要在多个集合中存储元素时，它们非常有用，这两者都适用于 crossbeam。Queue 是 Michael 和 Scott 队列。时期是一个缓存填充的 AtomicEpoch，缓存填充是一种禁用缓存行写冲突的技术，称为伪共享。AtomicEpoch 是 AtomicUsize 的包装器。那么，Global 是一个 Local 实例的链表——这些实例本身与线程固定的 Guards 关联——一个 Bag 的队列，我们尚未研究，与某些时期号（usize）和一个原子的全局 Epoch 关联。这种布局与算法描述所建议的非常相似。一旦唯一的 Global 被初始化，每个线程局部 Handle 都是通过调用 Collector::register 创建的，该调用在内部是 Local::register：

    pub fn register(collector: &Collector) -> Handle {
        unsafe {
            // Since we dereference no pointers in this block, it is 
            // safe to use `unprotected`.

            let local = Owned::new(Local {
                entry: Entry::default(),
                epoch: AtomicEpoch::new(Epoch::starting()),
                collector: UnsafeCell::new(
                    ManuallyDrop::new(collector.clone())
                ),
                bag: UnsafeCell::new(Bag::new()),
                guard_count: Cell::new(0),
                handle_count: Cell::new(1),
                pin_count: Cell::new(Wrapping(0)),
            }).into_shared(&unprotected());
            collector.global.locals.insert(local, &unprotected());
            Handle { local: local.as_raw() }
        }
    }

注意，特别是 collector.global.locals.insert(local, &unprotected()) 这个调用是将新创建的 Local 插入到 Global 局部列表中。（unprotected 是一个指向空指针的 Guard，而不是指向某个有效 Local）。每个固定线程都会在全局垃圾收集器的数据中注册一个 Local。实际上，在我们完成 defer 之前，让我们看看当 Guard 被丢弃时会发生什么：

impl Drop for Guard {
    #[inline]
    fn drop(&mut self) {
        if let Some(local) = unsafe { self.local.as_ref() } {
            local.unpin();
        }
    }
}

调用 Local 的 unpin 方法：

    pub fn unpin(&self) {
        let guard_count = self.guard_count.get();
        self.guard_count.set(guard_count - 1);

        if guard_count == 1 {
            self.epoch.store(Epoch::starting(), Ordering::Release);

            if self.handle_count.get() == 0 {
                self.finalize();
            }
        }
    }

回想一下，guard_count字段是参与线程的总数或为保持线程锁定而安排的守护者的总数。handle_count字段是一个类似的机制，但由Collector和Local使用。Local::finalize是动作发生的地方：

    fn finalize(&self) {
        debug_assert_eq!(self.guard_count.get(), 0);
        debug_assert_eq!(self.handle_count.get(), 0);

        // Temporarily increment handle count. This is required so that  
        // the following call to `pin` doesn't call `finalize` again.
        self.handle_count.set(1);
        unsafe {
            // Pin and move the local bag into the global queue. It's 
            // important that `push_bag` doesn't defer destruction 
            // on any new garbage.
            let guard = &self.pin();
            self.global().push_bag(&mut *self.bag.get(), guard);
        }
        // Revert the handle count back to zero.
        self.handle_count.set(0);

Local包含一个self.bag字段，其类型为UnsafeCell<Bag>。以下是Bag，在src/garbage.rs中定义：

pub struct Bag {
    /// Stashed objects.
    objects: ArrayVec<[Garbage; MAX_OBJECTS]>,
}

ArrayVec是这本书的新内容。它在ArrayVeccrate 中定义，是一个Vec，但具有最大容量限制。它是我们熟悉和喜爱的可增长向量，但不能无限分配。然后，Bag是一个可增长向量，包含Garbage，总大小限制为MAX_OBJECTS：

#[cfg(not(feature = "strict_gc"))]
const MAX_OBJECTS: usize = 64;
#[cfg(feature = "strict_gc")]
const MAX_OBJECTS: usize = 4;

尝试将垃圾推入超过MAX_OBJECTS的袋子将失败，向调用者发出信号，表明是时候收集一些垃圾了。Local::finalize具体做了什么，特别是与self.global().push_bag(&mut *self.bag.get(), guard)相关，是将Local的垃圾袋推入Global的垃圾袋，作为关闭Local的一部分。Global::push_bag是：

    pub fn push_bag(&self, bag: &mut Bag, guard: &Guard) {
        let bag = mem::replace(bag, Bag::new());

        atomic::fence(Ordering::SeqCst);

        let epoch = self.epoch.load(Ordering::Relaxed);
        self.queue.push((epoch, bag), guard);
    }

解除Guard的锁定可能会关闭一个Local，将其垃圾推入Global中标记为纪元的垃圾队列。现在我们明白了，让我们通过检查Local::defer来完成Guard::defer：

    pub fn defer(&self, mut garbage: Garbage, guard: &Guard) {
        let bag = unsafe { &mut *self.bag.get() };

        while let Err(g) = bag.try_push(garbage) {
            self.global().push_bag(bag, guard);
            garbage = g;
        }
    }

锁定的调用者通过调用defer将垃圾信号传递给其Guard。然后，Guard将此垃圾延迟到其Local，后者进入一个 while 循环，尝试将垃圾推入本地垃圾袋，但只要本地垃圾袋满了，就会将垃圾移入Global。

垃圾何时从Global中回收？答案是存在于我们尚未检查的函数中，即Local::pin。

crossbeam_epoch::Local::pin

回想一下，crossbeam_epoch::pin调用Handle::pin，后者又调用其Local上的pin。在Local::pin执行期间会发生什么？很多：

    pub fn pin(&self) -> Guard {
        let guard = Guard { local: self };

        let guard_count = self.guard_count.get();
        self.guard_count.set(guard_count.checked_add(1).unwrap());

Local的守护者计数增加，这是通过创建一个带有self的Guard来完成的。如果守护者计数之前为零：

        if guard_count == 0 {
            let global_epoch = 
         self.global().epoch.load(Ordering::Relaxed);
            let new_epoch = global_epoch.pinned();

这意味着在Local中没有其他活跃的参与者，并且Local需要查询全局纪元。全局纪元被加载为Local纪元：

              self.epoch.store(new_epoch, Ordering::Relaxed);
              atomic::fence(Ordering::SeqCst);

这里使用顺序一致性来确保未来和过去原子操作的一致性。最后，Local的pin_count增加，这可能会启动Global::collect：

            let count = self.pin_count.get();
            self.pin_count.set(count + Wrapping(1));

            // After every `PINNINGS_BETWEEN_COLLECT` try advancing the 
            // epoch and collecting some garbage.
            if count.0 % Self::PINNINGS_BETWEEN_COLLECT == 0 {
                self.global().collect(&guard);
            }
        }

        guard
    }

Local可以反复锁定和解锁，这时pin_count就派上用场。这种机制在我们的讨论中并未使用，但读者可以参考Guard::repin和Guard::repin_after。后者函数在混合网络调用和原子数据结构时特别有用，因为正如你回忆的那样，垃圾回收只能在纪元推进后进行，而纪元的推进通常是通过解除锁定来实现的。Global::collect非常简洁：

    pub fn collect(&self, guard: &Guard) {
        let global_epoch = self.try_advance(guard);

全球时代可能通过Global::try_advance向前推进，这种推进只有在全局Local列表中的每个Local都不在另一个时代，或者列表在检查期间没有被修改时才会发生。并发修改的检测是一个特别巧妙的技巧，它是 crossbeam-epoch 的私有List迭代的一部分。标记指针在这个迭代中扮演了一定的角色，强烈建议读者阅读并理解 crossbeam-epoch 使用的List实现：

        let condition = |item: &(Epoch, Bag)| {
            // A pinned participant can witness at most one epoch 
            advancement. Therefore, any bag
            // that is within one epoch of the current one cannot be 
            destroyed yet.
            global_epoch.wrapping_sub(item.0) >= 2
        };

        let steps = if cfg!(feature = "sanitize") {
            usize::max_value()
        } else {
            Self::COLLECT_STEPS
        };

        for _ in 0..steps {
            match self.queue.try_pop_if(&condition, guard) {
                None => break,
                Some(bag) => drop(bag),
            }
        }
    }

条件将被传递到 Global 的Queue::try_pop_if，它只会从队列中弹出与条件匹配的元素。我们在这里再次看到了算法的作用。回想一下self.queue :: Queue<(Epoch, Bag)>？垃圾袋只有在距离当前时代超过两个时代时才会从队列中取出，否则可能仍然存在对它们的活跃和危险的引用。这些步骤控制着最终将被收集的垃圾量，在时间与内存使用之间进行权衡。回想一下，每个新固定的线程都在参与这个过程，释放一些全局垃圾。

总结一下，当程序员调用线程固定时，这会为存储线程局部垃圾创建一个Local，并将其链接到Global上下文中所有Local的列表中。线程将尝试收集Global垃圾，在这个过程中可能推动时代向前。程序员在执行期间延迟的任何垃圾都会优先推入Local垃圾袋，如果这个袋满了，就会导致一些垃圾转移到Global袋中。当Local被取消固定时，Local袋中的任何垃圾都会转移到Global袋中。由于每个原子操作都需要对Guard的引用，因此每个原子操作隐式地与某个Local、某个时代相关联，并且可以安全地通过前面算法中概述的方法回收。

哎呀！

练习基于时代的 Treiber 栈

让我们将 crossbeam-epoch Treiber 栈进行彻底测试，以了解这种方法的表现。对我们来说，关键的兴趣领域将是：

• 每秒的推/弹周期

• 内存行为、水位线以及诸如此类的事情

• 缓存行为

我们将在 x86 和 ARM 上运行我们的程序，就像我们在前面的章节中所做的那样。我们的练习程序与上一节中的危险指针程序类似：

extern crate crossbeam;
#[macro_use]
extern crate lazy_static;
extern crate num_cpus;
extern crate quantiles;

use crossbeam::sync::TreiberStack;
use quantiles::ckms::CKMS;
use std::sync::Arc;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::{thread, time};

lazy_static! {
    static ref WORKERS: AtomicUsize = AtomicUsize::new(0);
    static ref COUNT: AtomicUsize = AtomicUsize::new(0);
}
static MAX_I: u32 = 67_108_864; // 2 ** 26

fn main() {
    let stk: Arc<TreiberStack<(u64, u64, u64)>> = Arc::new(TreiberStack::new());

    let mut jhs = Vec::new();

    let cpus = num_cpus::get();
    WORKERS.store(cpus, Ordering::Release);

    for _ in 0..cpus {
        let stk = Arc::clone(&stk);
        jhs.push(thread::spawn(move || {
            for i in 0..MAX_I {
                stk.push((i as u64, i as u64, i as u64));
                stk.pop();
                COUNT.fetch_add(1, Ordering::Relaxed);
            }
            WORKERS.fetch_sub(1, Ordering::Relaxed)
        }))
    }

    let one_second = time::Duration::from_millis(1_000);
    let mut iter = 0;
    let mut cycles: CKMS<u32> = CKMS::new(0.001);
    while WORKERS.load(Ordering::Relaxed) != 0 {
        let count = COUNT.swap(0, Ordering::Relaxed);
        cycles.insert((count / cpus) as u32);
        println!(
            "CYCLES PER SECOND({}):\n  25th: \
             {}\n  50th: {}\n  75th: \
             {}\n  90th: {}\n  max:  {}\n",
            iter,
            cycles.query(0.25).unwrap().1,
            cycles.query(0.50).unwrap().1,
            cycles.query(0.75).unwrap().1,
            cycles.query(0.90).unwrap().1,
            cycles.query(1.0).unwrap().1
        );
        thread::sleep(one_second);
        iter += 1;
    }

    for jh in jhs {
        jh.join().unwrap();
    }
}

我们有与目标机器中 CPU 总数相等的多个工作线程，每个线程执行一次推入然后立即弹出栈的操作。每秒左右，主线程将COUNT的值交换为 0，并将该值投入到一个分位数估计结构中——在第四章中更详细地讨论了这一点，同步与发送——Rust 并发的基石——并打印出每秒记录的周期摘要，按 CPU 数量缩放。工作线程循环到MAX_I，这个值任意设置为2**26的小值。当工作线程完成循环后，它会减少WORKERS的值并退出。一旦WORKERS达到零，主循环也会退出。

在我的 x86 机器上，这个程序退出大约需要 38 秒，输出如下：

CYCLES PER SECOND(0):
  25th: 0
  50th: 0
  75th: 0
  90th: 0
  max:  0

CYCLES PER SECOND(1):
  25th: 0
  50th: 0
  75th: 1739270
  90th: 1739270
  max:  1739270

...

CYCLES PER SECOND(37):
  25th: 1738976
  50th: 1739528
  75th: 1740474
  90th: 1757650
  max:  1759459

CYCLES PER SECOND(38):
  25th: 1738868
  50th: 1739528
  75th: 1740452
  90th: 1757650
  max:  1759459

与 x86 危险实现相比，它总共需要 58 秒。x86 perf 运行结果如下：

> perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses target/release/epoch_stack > /dev/null

 Performance counter stats for 'target/release/epoch_stack':

     148830.337380      task-clock (msec)         #    3.916 CPUs utilized
             1,043      context-switches          #    0.007 K/sec
             1,039      page-faults               #    0.007 K/sec
   429,969,505,981      cycles                    #    2.889 GHz
   161,901,052,886      instructions              #    0.38  insn per cycle
    27,531,697,676      branches                  #  184.987 M/sec
       627,050,474      branch-misses             #    2.28% branches
    11,885,394,803      cache-references          #   79.859 M/sec
         1,772,308      cache-misses              #    0.015 % cache refs

      38.004548310 seconds time elapsed

在基于纪元的处理方法中，执行指令的总数要低得多，这与本节开头讨论中的分析相吻合。即使只有一个危险指针，基于纪元的处理方法所做的工也要少得多。在我的 ARM 机器上，程序运行到完成大约需要 72 秒，输出如下：

CYCLES PER SECOND(0):
  25th: 0
  50th: 0
  75th: 0
  90th: 0
  max:  0

CYCLES PER SECOND(1):
  25th: 0
  50th: 0
  75th: 921743
  90th: 921743
  max:  921743

...

CYCLES PER SECOND(71):
  25th: 921908
  50th: 922326
  75th: 922737
  90th: 923235
  max:  924084

CYCLES PER SECOND(72):
  25th: 921908
  50th: 922333
  75th: 922751
  90th: 923235
  max:  924084

与 ARM 危险实现相比，它总共需要 463 秒！ARM perf 运行结果如下：

> perf stat --event task-clock,context-switches,page-faults,cycles,instructions,branches,branch-misses,cache-references,cache-misses target/release/epoch_stack > /dev/null

 Performance counter stats for 'target/release/epoch_stack':

     304880.898057      task-clock (msec)         #    3.959 CPUs utilized
                 0      context-switches          #    0.000 K/sec
               248      page-faults               #    0.001 K/sec
   364,139,169,537      cycles                    #    1.194 GHz
   215,754,991,724      instructions              #    0.59  insn per cycle
    28,019,208,815      branches                  #   91.902 M/sec
     3,525,977,068      branch-misses             #   12.58% branches
   105,165,886,677      cache-references          #  344.941 M/sec
     1,450,538,471      cache-misses              #    1.379 % cache refs

      77.014340901 seconds time elapsed

与同一处理器架构上的危险指针实现相比，执行指令的数量大大减少。顺便提一下，值得注意的一点是，x86 和 ARM 版本的epoch_stack内存使用量都低于危险指针栈实现，尽管它们都不是内存消耗大户，每个只消耗了几千字节。如果我们的纪元线程在离开其纪元之前长时间休眠——比如说一秒钟左右——那么在执行过程中内存使用量会增加。鼓励读者在自己的系统上造成混乱。

权衡

在本章概述的三种方法中，crossbeam-epoch 在测量和文献讨论中都是最快的。更快的技巧，基于静默状态的内存回收，在本章中没有讨论，因为它不适合用户空间程序，而且在 Rust 中没有现成的实现。此外，库的作者已经投入了多年的工作来实现它：它有很好的文档记录，并在多个 CPU 架构上的现代 Rust 中运行。

该方法的传统问题——即线程引入到固定关键部分的长时间延迟，导致长期存在的时代和垃圾积累——在 API 中通过Guard能够任意重新固定的能力得到解决。将标准库的AtomicPtr数据结构过渡到 crossbeam 是一个项目，但是一个可接近的项目。正如我们所见，crossbeam-epoch 确实引入了一些开销，包括缓存填充和线程同步。这种开销是最小的，并且预计会随着时间的推移而改善。

摘要

在本章中，我们讨论了三种内存回收技术：引用计数、危险指针和基于时代的回收。每种方法都比前一种更快，尽管每种方法都有其权衡。引用计数产生的开销最大，必须谨慎地将其集成到你的数据结构中，除非 Arc 符合你的需求，这完全有可能。危险指针需要识别危险，即导致无法回收内存的内存访问，这种访问需要某种类型的协调。这种方法在每次访问危险指针时都会产生开销，如果必须遍历危险结构，这将是昂贵的。最后，基于时代的回收在线程固定时产生开销，这表示时代的开始，可能需要新固定的线程参与垃圾回收。在固定之后，内存访问不会产生额外的开销，如果你正在执行遍历或以其他方式在固定部分包含许多内存操作，这将是一个巨大的胜利。

crossbeam 库做得非常好。除非你有专门设计为不需要分配或在没有垃圾回收的情况下处理在宽松内存系统上的分配的原子数据结构，否则强烈建议你在 Rust 中进行原子编程时将 crossbeam 视为不可或缺的一部分，至少在撰写本文时是这样的。

在下一章中，我们将离开原子编程的领域，讨论并行编程的高级方法，使用线程池和数据并行迭代器。

进一步阅读

• 危险指针：无锁对象的内存回收安全方法，Maged Michael。本文介绍了本章讨论的危险指针回收技术。该论文特别讨论了与引用计数相比的新发明技术，并展示了使用危险指针技术构建安全的 Michael 和 Scott 队列。

• 实用的无锁编程，Keir Fraser。这是 Keir Fraser 的博士论文，相当长，涉及引入抽象以简化无锁结构的编写——其中之一是基于时代的回收——以及引入无锁搜索结构、跳表、二叉搜索树和红黑树。强烈推荐。

• Performance of Memory Reclamation for Lockless Synchronization，托马斯·哈特等人。这篇论文概述了四种技术，这些技术都在本书的第六章 Atomics – the Primitives of Synchronization 中有所提及，其中三种在本章中进行了深入讨论。此外，论文介绍了一种针对基于纪元的回收的优化，如果作者没有弄错的话，这已经影响了 crossbeam。这篇论文是算法的绝佳概述，并以定义良好的方式提供了算法性能的比较测量。

• RFCs for changes to Crossbeam，可在github.com/crossbeam-rs/rfcs找到。这个 GitHub 仓库是关于对 crossbeam 库进行大规模更改的主要讨论点，其讨论内容特别值得阅读。例如，RFC 2017-07-23-relaxed-memory 概述了 crossbeam 在松散内存系统上运行所需的变化，这是一个在文献中很少讨论的话题。

• CDSCHECKER: Checking Concurrent Data Structures Written with C/C++ Atomics，布莱恩·诺里斯和布莱恩·德姆斯基。这篇论文介绍了一个工具，用于根据 C++11/LLVM 内存模型检查并发数据结构的行为。鉴于松散内存排序可能有多么令人困惑，这个工具在进行 C++工作时非常有用。我不知道有 Rust 的类似工具，但希望这会被视为一个机会，让一些有才华的人阅读。祝你好运，你。

• A Promising Semantics for Relaxed-Memory Concurrency，金浩恩·康等人。对 C++/LLVM 中提出的内存模型进行推理非常困难。尽管多年来许多人已经深入思考过这个问题，但仍然有活跃的研究致力于将此模型形式化以验证优化器和算法的正确功能。请与诺里斯和德姆斯基的《CDSCHECKER》一起阅读这篇论文。

第八章：高级并行性 – 线程池、并行迭代器和进程

在前面的章节中，我们介绍了 Rust 编程语言中并发的基本机制。在第四章，Sync 和 Send – Rust 并发的基石中，我们讨论了 Rust 类型系统与并发程序之间的相互作用，以及 Rust 如何确保在这种最困难的情形下内存安全。在第五章，锁 – Mutex、Condvar、屏障和 RWLock中，我们讨论了更高层次、所谓的粗粒度同步机制，这在许多语言中都很常见。在第六章，原子操作 – 同步的原始操作和第七章，原子操作 – 安全地回收内存中，我们讨论了现代机器上可用的更精细的同步原语，这些原语通过 Rust 的并发内存模型暴露出来。这一切都很好，尽管我们已经深入研究了某些库或数据结构，但我们还没有看到所有这些工具对程序结构的影响，或者根据需要如何在 CPU 之间分配工作负载。

在本章中，我们将探讨不涉及手动锁定或原子同步的高级技术，以利用并发机器。我们将检查线程池，这是一种在其他编程语言中常见的技巧，使用 rayon 库进行数据并行性，并在遗传编程项目的上下文中演示多进程，这将带我们进入下一章。

到本章结束时，我们将：

• 探索了线程池的实现

• 理解了线程池如何与 rayon 的操作相关

• 深入探索了 rayon 的内部机制

• 在一个非平凡练习中演示了 rayon 的使用

技术要求

本章需要安装一个有效的 Rust 环境。验证安装的细节在第一章，预备知识 – 计算机架构和 Rust 入门中有介绍。需要一个 pMARS 可执行文件，并且必须位于您的 PATH 中。请遵循 pMARS (www.koth.org/pmars/) 源树中的说明来构建。

您可以在 GitHub 上找到本书项目的源代码：github.com/PacktPublishing/Hands-On-Concurrency-with-Rust。本章的源代码位于 Chapter08。

线程池

到目前为止，在这本书中，每当我们需要一个线程时，我们只是简单地调用了 thread::spawn。这并不一定是一件安全的事情。让我们检查两个存在共同缺陷的项目——潜在的操作系统线程过度消耗。第一个将明显有缺陷，第二个则不那么明显。

Slowloris 攻击——攻击每个连接一个线程的服务器

每个连接一个线程的架构是一种网络架构，它为每个入站连接分配一个操作系统线程。这对于服务器来说效果很好，因为服务器将接收的连接总数与服务器可用的 CPU 数量相对相似。根据操作系统不同，这种架构通常会减少网络事务的响应时间延迟，这是一个很好的额外优势。线程-连接系统的主要缺陷与 slowloris 攻击有关。在这种攻击方式中，恶意用户向服务器打开一个连接——这是一个相对便宜的操作，只需要一个文件处理器，并且简单地保持连接。线程-连接系统可以通过积极超时空闲连接来减轻 slowloris 攻击，攻击者可以通过以非常慢的速度通过连接发送数据来减轻攻击，例如每 100 毫秒发送一个字节。攻击者，如果只是在受信任的网络内部部署，所花费的资源非常少来执行他们的攻击。同时，对于系统中的每个新连接，服务器被迫分配一个完整的堆栈帧，并被迫将另一个线程塞入操作系统调度器。这并不便宜。

服务器

让我们构建一个易受攻击的服务器，然后将其摧毁。按照以下方式布局你的Cargo.toml：

[package]
name = "overwhelmed_tcp_server"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
clap = "2.31"
slog = "2.2"
slog-term = "2.4"
slog-async = "2.3"

[[bin]]
name = "server"

[[bin]]
name = "client"

库 slog (crates.io/crates/slog) 是一个结构化日志库，我在生产系统中强烈推荐使用。Slog 本身非常灵活，更像是构建日志系统的框架，而不是一个固定的东西。在这里，我们将向终端进行日志记录，这正是 slog-term 的作用所在。slog-async依赖关系将实际的写入操作推迟到终端，在我们的例子中，推迟到一个专用线程。当 slog 通过网络而不是快速向终端发送日志时，这种专用性更为重要。我们不会深入探讨本书中的 slog，但文档非常全面，我想如果你还没有使用 slog，你也会欣赏它的。库 clap (crates.io/crates/clap) 是一个命令行解析库，我也强烈推荐在生产系统中使用。最后要注意的是，在这个项目中，我们生成了两个二进制文件，分别称为server和client。让我们首先深入研究server。像往常一样，我们的项目从前言开始：

#[macro_use]
extern crate slog;
extern crate clap;
extern crate slog_async;
extern crate slog_term;

use clap::{App, Arg};
use slog::Drain;
use std::io::{self, BufRead, BufReader, BufWriter, Write};
use std::net::{TcpListener, TcpStream};

use std::sync::atomic::{AtomicUsize, Ordering};
use std::thread;

static TOTAL_STREAMS: AtomicUsize = AtomicUsize::new(0);

到这本书的这一部分，这里没有什么令人惊讶的。我们导入我们刚刚讨论的外部库以及大量标准库材料。与本书前面的内容相比，与网络相关的导入是不熟悉的，但我们会简要介绍这一点。最后，我们在程序顶部创建了一个静态的TOTAL_STREAMS，服务器将使用它来跟踪它已连接的总 TCP 流数。main函数开始设置 slog：

fn main() {
    let decorator = slog_term::TermDecorator::new().build();
    let drain = slog_term::CompactFormat::new(decorator).build().fuse();
    let drain = slog_async::Async::new(drain).build().fuse();
    let root = slog::Logger::root(drain, o!());

具体的细节留给了读者在 slog 的文档中去发现。接下来，我们设置 clap 和parse程序参数：

    let matches = App::new("server")
        .arg(
            Arg::with_name("host")
                .long("host")
                .value_name("HOST")
                .help("Sets which hostname to listen on")
                .takes_value(true),
        )
        .arg(
            Arg::with_name("port")
                .long("port")
                .value_name("PORT")
                .help("Sets which port to listen on")
                .takes_value(true),
        )
        .get_matches();

    let host: &str = matches.value_of("host").unwrap_or("localhost");
    let port = matches
        .value_of("port")
        .unwrap_or("1987")
        .parse::<u16>()
        .expect("port-no not valid");

这里细节也留给了读者在 clap 的文档中去发现，但希望意图已经足够清晰。我们设置了两个参数，host和port，服务器将监听这些参数上的连接。说到：

    let listener = TcpListener::bind((host, port)).unwrap();

注意，如果服务器无法建立连接，我们将取消包装。这是对用户不友好的，在一个值得生产的应用程序中，你应该匹配错误并打印出一个友好、有帮助的消息来解释错误。现在服务器正在监听新的连接，我们创建一个特定于服务器的记录器并开始处理传入的连接：

    let server = root.new(o!("host" => host.to_string(),
                             "port" => port));
    info!(server, "Server open for business! :D");

    let mut joins = Vec::new();
    for stream in listener.incoming() {
        if let Ok(stream) = stream {
            let stream_no = TOTAL_STREAMS.fetch_add(1, 
            Ordering::Relaxed);
            let log = root.new(o!("stream-no" => stream_no,
                   "peer-addr" => stream.peer_addr()
                                  .expect("no peer address")
                                  .to_string()));
            let writer = BufWriter::new(
                             stream.try_clone()
                             .expect("could not clone stream"));
            let reader = BufReader::new(stream);
            match handle_client(log, reader, writer) {
                Ok(handler) => {
                    joins.push(handler);
                }
                Err(err) => {
                    error!(server, 
                           "Could not make client handler. {:?}",
                           err);
                }
            }
        } else {
            info!(root, "Shutting down! {:?}", stream);
        }
    }

    info!(
        server,
        "No more incoming connections. Draining existing connections."
    );
    for jh in joins {
        if let Err(err) = jh.join() {
            info!(server, 
                  "Connection handler died with error: {:?}", 
                  err);
        }
    }
}

这里关键的是handle_client(log, reader, writer)这个函数。这个函数接受新创建的stream :: TcpStream——以它的缓冲读取器和写入器形式——并返回std::io::Result<JoinHandler<()>>。我们将直接看到这个函数的实现。在此之前，顺便提一下，记住给你的 IO 添加缓冲非常重要。如果我们没有在这里放置BufWriter和BufReader，那么在大多数系统中，对TcpStream的每次读取和写入都会导致系统调用，在网络中进行逐字节传输。对于所有相关人员来说，以批量的方式读取和写入要显著高效得多，这正是BufReader和BufWriter实现所负责的。我已经数不清有多少程序因为明智地应用了缓冲 IO 而变得更快。不幸的是，我们不会深入探讨BufReader和BufWriter的实现，因为它们超出了本书的范围。如果你已经读到这儿，并且我做得不错地解释了，那么你已经学到了理解实现所需的一切，鼓励你在方便的时候深入研究。注意，这里我们还在为handle_client返回的JoinHandler<()>分配一个向量。这并不一定是理想的。考虑如果第一个连接是长期存在的，而后续的连接都是短暂的。尽管这些处理器已经完成，但它们不会被清除，程序将逐渐增加内存消耗。解决这个问题的方式将取决于程序本身，但至少在这里，忽略这些处理器并在工作线程中强制进行事务退出将足够。为什么？因为服务器只是在回声：

fn handle_client(
    log: slog::Logger,
    mut reader: BufReader<TcpStream>,
    mut writer: BufWriter<TcpStream>,
) -> io::Result<thread::JoinHandle<()>> {
    let builder = thread::Builder::new();
    builder.spawn(move || {
        let mut buf = String::with_capacity(2048);

        while let Ok(sz) = reader.read_line(&mut buf) {
            info!(log, "Received a {} bytes: {}", sz, buf);
            writer
                .write_all(&buf.as_bytes())
                .expect("could not write line");
            buf.clear();
        }
        TOTAL_STREAMS.fetch_sub(1, Ordering::Relaxed);
    })
}

无论如何，网络协议必须能够应对任一端挂起的情况，这是由于网络的不可靠性。事实上，那些喜欢这本书，特别是第六章“原子——同步的原始”和第七章“原子——安全地回收内存”的读者，将会很高兴地了解到分布式系统面临着许多相同的困难，而且还增加了不可靠传输的额外好处。无论如何，请注意handle_client并没有做太多，只是使用thread::Builder API 构建线程，我们在第五章“锁——Mutex、Condvar、Barriers 和 RWLock”中讨论过。否则，它是一个相当标准的 TCP 回显。

让我们看看服务器的工作情况。在项目的顶部运行cargo run --release --bin server，你应该会得到类似以下的结果：

> cargo run --release --bin server
    Finished release [optimized] target(s) in 0.26 secs
     Running `target/release/server`
host: localhost
 port: 1987
  Apr 22 21:31:14.001 INFO Server open for business! :D

到目前为止一切顺利。这个服务器正在监听本地的 1987 端口。在另一个终端，你可以运行 telnet 到服务器：

> telnet localhost 1987
Trying ::1...
Connected to localhost.
Escape character is '^]'.
hello server

我已经向我的运行实例发送了hello server，但由于写入缓冲区的行为，我还没有收到响应。显式刷新可以纠正这个问题，但会以性能下降为代价。是否放置刷新完全取决于设置。这里？嗯。

服务器尽职尽责地记录了交互：

stream-no: 0
 peer-addr: [::1]:65219
  Apr 22 21:32:54.943 INFO Received a 14 bytes: hello server

客户端

我们服务器的真正挑战来自于一个特别构造的客户端。在我们看到客户端的实际运行情况之前，让我们先看看它。前置代码是典型的：

#[macro_use]
extern crate slog;
extern crate clap;
extern crate slog_async;
extern crate slog_term;

use clap::{App, Arg};
use slog::Drain;
use std::net::TcpStream;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::{thread, time};

static TOTAL_STREAMS: AtomicUsize = AtomicUsize::new(0);

事实上，这个客户端的前置代码与服务器非常接近。同样，main函数也是如此，我们很快就会看到。正如这本书中的许多其他程序一样，我们为报告程序的行为分配了一个线程。在这个客户端中，这个线程运行了长生的report：

fn report(log: slog::Logger) {
    let delay = time::Duration::from_millis(1000);
    let mut total_streams = 0;
    loop {
        let streams_per_second = TOTAL_STREAMS.swap(0, Ordering::Relaxed);
        info!(log, "Total connections: {}", total_streams);
        info!(log, "Connections per second: {}", streams_per_second);
        total_streams += streams_per_second;
        thread::sleep(delay);
    }
}

每秒report交换TOTAL_STREAMS，保持自己的total_streams，并使用重置值作为每秒的量度。这在我们这本书中之前没有见过。现在，在main函数中，我们设置了记录器并解析与服务器相同的命令选项：

fn main() {
    let decorator = slog_term::TermDecorator::new().build();
    let drain = slog_term::CompactFormat::new(decorator).build().fuse();
    let drain = slog_async::Async::new(drain).build().fuse();
    let root = slog::Logger::root(drain, o!());

    let matches = App::new("server")
        .arg(
            Arg::with_name("host")
                .long("host")
                .value_name("HOST")
                .help("Sets which hostname to listen on")
                .takes_value(true),
        )
        .arg(
            Arg::with_name("port")
                .long("port")
                .value_name("PORT")
                .help("Sets which port to listen on")
                .takes_value(true),
        )
        .get_matches();

    let host: &str = matches.value_of("host").unwrap_or("localhost");
    let port = matches
        .value_of("port")
        .unwrap_or("1987")
        .parse::<u16>()
        .expect("port-no not valid");

    let client = root.new(o!("host" => host.to_string(), "port" => port));
    info!(client, "Client ready to be mean. >:)");

在main中，我们启动了报告线程并忽略了它的句柄：

    let reporter_log = root.new(o!("meta" => "report"));
    let _ = thread::spawn(|| report(reporter_log));

这就只剩下提交 slowloris 攻击了，这对客户端来说令人失望地简单：

    let mut streams = Vec::with_capacity(2048);
    loop {
        match TcpStream::connect((host, port)) {
            Ok(stream) => {
                TOTAL_STREAMS.fetch_add(1, Ordering::Relaxed);
                streams.push(stream);
            }
            Err(err) => error!(client, 
                               "Connection rejected with error: {:?}", 
                               err),
        }
    }
}

嗯，就是这样，一个简单的循环尽可能快地连接。一个更复杂的设置会通过套接字发送涓流数据来击败积极的超时或限制连接的总数以避免怀疑，并与其他机器协调一致。

网络上的恶作剧是一场没有人真正赢的军备竞赛，这是道德。

不管怎样，让我们看看这个客户端的实际运行情况。如果你运行cargo run --release --bin client，你应该会得到以下结果：

> cargo run --release --bin client
    Finished release [optimized] target(s) in 0.22 secs
     Running `target/release/client`
host: localhost
 port: 1987
  Apr 22 21:50:49.200 INFO Client ready to be mean. >:)
meta: report
 Apr 22 21:50:49.200 INFO Total connections: 0
 Apr 22 21:50:49.201 INFO Connections per second: 0
 Apr 22 21:50:50.200 INFO Total connections: 0
 Apr 22 21:50:50.200 INFO Connections per second: 1160
 Apr 22 21:50:51.204 INFO Total connections: 1160
 Apr 22 21:50:51.204 INFO Connections per second: 1026
 Apr 22 21:50:52.204 INFO Total connections: 2186
 Apr 22 21:50:52.204 INFO Connections per second: 915

你会在服务器日志中找到一堆错误，以及由于操作系统调度器抖动导致的高 CPU 负载。这不是一个好时机。

这里最终的问题是，我们允许外部方，即客户，决定我们程序的分配模式。固定大小可以制作出更安全的软件。在这种情况下，我们将在启动时固定线程总数，从而将服务器能够维持的连接数限制在一个相对较低的数量。尽管如此，这将是一个安全的低数量。请注意，将整个操作系统线程分配给单个网络连接的不足之处正是激发了 20 世纪 90 年代末的 C10K 问题，导致了现代操作系统更高效的轮询能力。这些轮询系统调用是 Mio 和 Tokio 的基础，尽管对它们的讨论远远超出了本书的范围。查阅它们。这是 Rust 网络技术的未来。

这个程序需要一种方法来固定可用于连接的线程数量。这正是线程池的作用。

线程池服务器

让我们将过载的 TCP 服务器调整为使用固定数量的线程。我们将启动一个新的项目，其Cargo.toml看起来如下：

[package]
name = "fixed_threads_server"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
clap = "2.31"
slog = "2.2"
slog-term = "2.4"
slog-async = "2.3"
threadpool = "1.7"

[[bin]]
name = "server"

[[bin]]
name = "client"

这几乎与无界线程项目完全相同，只是名称已从overwhelmed_tpc_server更改为fixed_threads_tcp_server，并且我们添加了一个新的依赖项–threadpool。在 crates 中可以找到几个不同的、稳定的线程池库，每个库都有略微不同的功能集或焦点。例如，workerpool 项目(crates.io/crates/workerpool)几乎具有与 threadpool 相同的 API，但它在类型级别强制执行与工作线程的输入/输出通信，而 threadpool 要求用户自己建立这种通信。在这个项目中，我们没有与工作线程通信的需求。

服务器的前置代码仅略有改变：

#[macro_use]
extern crate slog;
extern crate clap;
extern crate slog_async;
extern crate slog_term;
extern crate threadpool;

use clap::{App, Arg};
use slog::Drain;
use std::io::{BufRead, BufReader, BufWriter, Write};
use std::net::{TcpListener, TcpStream};
use std::sync::atomic::{AtomicUsize, Ordering};
use threadpool::ThreadPool;

static TOTAL_STREAMS: AtomicUsize = AtomicUsize::new(0);

这里的唯一变化是引入了线程池库和删除了一些未使用的导入。我们的handle_client实现基本上也是相同的，但值得注意的是没有启动线程：

fn handle_client(
    log: slog::Logger,
    mut reader: BufReader<TcpStream>,
    mut writer: BufWriter<TcpStream>,
) -> () {
    let mut buf = String::with_capacity(2048);

    while let Ok(sz) = reader.read_line(&mut buf) {
        info!(log, "Received a {} bytes: {}", sz, buf);
        writer
            .write_all(&buf.as_bytes())
            .expect("could not write line");
        buf.clear();
    }
    TOTAL_STREAMS.fetch_sub(1, Ordering::Relaxed);
}

我们的主函数，同样，也非常相似。我们设置日志记录器并解析应用程序选项，添加一个新的max_connections选项：

fn main() {
    let decorator = slog_term::TermDecorator::new().build();
    let drain = slog_term::CompactFormat::new(decorator).build().fuse();
    let drain = slog_async::Async::new(drain).build().fuse();
    let root = slog::Logger::root(drain, o!());

    let matches = App::new("server")
        .arg(
            Arg::with_name("host")
                .long("host")
                .value_name("HOST")
                .help("Sets which hostname to listen on")
                .takes_value(true),
        )
        .arg(
            Arg::with_name("port")
                .long("port")
                .value_name("PORT")
                .help("Sets which port to listen on")
                .takes_value(true),
        )
        .arg(
            Arg::with_name("max_connections")
                .long("max_connections")
                .value_name("CONNECTIONS")
                .help("Sets how many connections (thus,\
                       threads) to allow simultaneously")
                .takes_value(true),
        )
        .get_matches();

    let host: &str = matches.value_of("host").unwrap_or("localhost");
    let port = matches
        .value_of("port")
        .unwrap_or("1987")
        .parse::<u16>()
        .expect("port-no not valid");
    let max_connections = matches
        .value_of("max_connections")
        .unwrap_or("256")
        .parse::<u16>()
        .expect("max_connections not valid");

注意，max_connections是u16。这是任意的，并且在某些特殊情况下可能会低估一些较大的机器。但这对今天的大多数硬件来说是一个合理的范围。就像之前一样，我们将日志记录器调整为包括主机和端口信息：

    let listener = TcpListener::bind((host, port)).unwrap();
    let server = root.new(o!("host" => host.to_string(), "port" => port));
    info!(server, "Server open for business! :D");

到目前为止，一切顺利。在服务器开始接受传入连接之前，它需要一个线程池。如下所示：

    let pool: ThreadPool = threadpool::Builder::new()
        .num_threads(max_connections as usize)
        .build();

关于threadpool::Builder的确切作用和工作方式，我们将在下一节中详细说明，目前我们只依靠文档来指导。因此，我们现在有了具有max_connection可能活跃线程的ThreadPool。这个池实现不会限制可以运行在池中的总作业数量，而是将它们收集在队列中。这并不适合我们的目的，我们的目标是拒绝无法服务的连接。这是我们可以解决的问题：

    for stream in listener.incoming() {
        if let Ok(stream) = stream {
            if pool.active_count() == (max_connections as usize) {
                info!(
                    server,
                    "Max connection condition reached, rejecting incoming"
                );
            } else {
                let stream_no = TOTAL_STREAMS.fetch_add(
                                    1, 
                                    Ordering::Relaxed
                                );
                let log = root.new(o!("stream-no" => stream_no,
                   "peer-addr" => stream.peer_addr()
                                  .expect("no peer address")
                                  .to_string()));
                let writer = BufWriter::new(stream.try_clone()
                             .expect("could not clone stream"));
                let reader = BufReader::new(stream);
                pool.execute(move || handle_client(log, reader, writer));
            }
        } else {
            info!(root, "Shutting down! {:?}", stream);
        }
    }

接受循环与上一个服务器大致相同，只是在循环的顶部，我们会检查pool.active_count()与配置的max_connections，如果运行中的工作者线程数量达到容量，则拒绝连接；否则，我们接受连接并在池中执行它。最后，就像之前一样，当传入的套接字关闭时，服务器会排空连接：

    info!(
        server,
        "No more incoming connections. \
         Draining existing connections."
    );
    pool.join();
}

上一节中展示的客户端可以不加修改地应用于这个服务器。如果读者检查书籍的源代码仓库，他们将发现项目之间的客户端是相同的。

与上一个服务器不同，这个服务器实现不会受到不断增长的JoinHandle向量的困扰。池会注意从其内部缓冲区中移除恐慌的线程，而我们也会注意不要允许更多的工作者线程数量超过可用的线程数量。让我们来看看这是如何工作的！

深入了解线程池

让我们深入研究线程池，了解其实现方式。希望到这本书的这一部分，您已经对如何构建自己的线程池库有了大致的了解。在继续之前，考虑一下您的想法与这种特定方法相比如何，我们将检查这个库（crates.io/crates/threadpool）的 SHA a982e060ea2e3e85113982656014b212c5b88ba2。

线程池 crate 并未完整列出。您可以在书籍的源代码仓库中找到完整的列表。

让我们先看看项目的Cargo.toml文件：

[package]

name = "threadpool"
version = "1.7.1"
authors = ["The Rust Project Developers", "Corey Farwell <coreyf@rwell.org>", "Stefan Schindler <dns2utf8@estada.ch>"]
license = "MIT/Apache-2.0"
readme = "README.md"
repository = "https://github.com/rust-threadpool/rust-threadpool"
homepage = "https://github.com/rust-threadpool/rust-threadpool"
documentation = "https://docs.rs/threadpool"
description = """
A thread pool for running a number of jobs on a fixed set of worker threads.
"""
keywords = ["threadpool", "thread", "pool", "threading", "parallelism"]
categories = ["concurrency", "os"]

[dependencies]
num_cpus = "1.6"

相对简单。唯一的依赖项是num_cpus，这是一个用于确定机器上逻辑和物理核心数量的小型库。在 Linux 上，它读取/proc/cpuinfo。在其他操作系统上，如 BSD 或 Windows，该库会进行系统调用。这是一个巧妙的小型库，如果您需要学习如何在不同的操作系统上针对不同的函数实现，那么阅读它是非常有价值的。从线程池的Cargo.toml中我们可以得出的关键信息是，它几乎完全由标准库中的工具构建而成。实际上，库中只有一个实现文件，即src/lib.rs。从现在开始，我们将讨论的所有代码都可以在该文件中找到。

现在，让我们理解之前章节中看到的构建器模式。Builder类型定义如下：

#[derive(Clone, Default)]
pub struct Builder {
    num_threads: Option<usize>,
    thread_name: Option<String>,
    thread_stack_size: Option<usize>,
}

在前面的部分中，我们只填充了num_threads。thread_stack_size用于控制池线程的堆栈大小。截至写作时，线程堆栈大小默认为两兆字节。标准库的std::thread::Builder::stack_size允许我们手动设置此值。例如，在我们的线程-连接示例中，我们可以将堆栈大小设置得显著更低，从而在相同的硬件上获得更多的线程。毕竟，每个线程分配的存储非常少，尤其是如果我们已经采取了只读取固定缓冲区的步骤。thread_name字段，就像堆栈大小一样，是std::thread::Builder::name的开关。也就是说，它允许用户为池中的所有线程设置线程名称，它们将共享这个名称。根据我的经验，命名线程是相对罕见的事情，尤其是在池中，但有时它对日志记录很有用。

池构建器主要按你预期的那样工作，公共函数设置Builder结构体中的字段。实现变得有趣的地方是Builder::build：

    pub fn build(self) -> ThreadPool {
        let (tx, rx) = channel::<Thunk<'static>>();

        let num_threads = self.num_threads.unwrap_or_else(num_cpus::get);

        let shared_data = Arc::new(ThreadPoolSharedData {
            name: self.thread_name,
            job_receiver: Mutex::new(rx),
            empty_condvar: Condvar::new(),
            empty_trigger: Mutex::new(()),
            join_generation: AtomicUsize::new(0),
            queued_count: AtomicUsize::new(0),
            active_count: AtomicUsize::new(0),
            max_thread_count: AtomicUsize::new(num_threads),
            panic_count: AtomicUsize::new(0),
            stack_size: self.thread_stack_size,
        });

        // Threadpool threads
        for _ in 0..num_threads {
            spawn_in_pool(shared_data.clone());
        }

        ThreadPool {
            jobs: tx,
            shared_data: shared_data,
        }
    }

这里有很多内容。让我们一步一步来。首先，那个通道是我们在第四章中详细讨论的std::sync::mpsc::channel，同步与发送 - Rust 并发的基础。那里不熟悉的是Thunk。结果证明，它是一个类型别名：

type Thunk<'a> = Box<FnBox + Send + 'a>;

现在，什么是FnBox？它是一个小的特质：

trait FnBox {
    fn call_box(self: Box<Self>);
}

impl<F: FnOnce()> FnBox for F {
    fn call_box(self: Box<F>) {
        (*self)()
    }
}

它是我们在第三章中遇到的FnOnce特质，Rust 内存模型 - 所有权、引用和操作，所以如果你读过那一章，你就知道F只会被调用一次。函数闭包的装箱意味着其捕获的变量可以在堆上使用，并且当池调用者将闭包移出作用域时不会进行清理。太好了。现在，让我们回到构建并查看shared_data：

        let shared_data = Arc::new(ThreadPoolSharedData {
            name: self.thread_name,
            job_receiver: Mutex::new(rx),
            empty_condvar: Condvar::new(),
            empty_trigger: Mutex::new(()),
            join_generation: AtomicUsize::new(0),
            queued_count: AtomicUsize::new(0),
            active_count: AtomicUsize::new(0),
            max_thread_count: AtomicUsize::new(num_threads),
            panic_count: AtomicUsize::new(0),
            stack_size: self.thread_stack_size,
        });

好吧，几个原子usize，一个条件变量，一个互斥锁来保护 thunk 通道的接收端，以及一个将与条件变量配对的互斥锁。通过阅读结构体的成员变量，你可以了解到很多信息，只要有一点背景知识。ThreadPoolSharedData的实现是简短的：

impl ThreadPoolSharedData {
    fn has_work(&self) -> bool {
        self.queued_count.load(Ordering::SeqCst) > 0 || 
        self.active_count.load(Ordering::SeqCst) > 0
    }

    /// Notify all observers joining this pool if there
    /// is no more work to do.
    fn no_work_notify_all(&self) {
        if !self.has_work() {
            *self.empty_trigger
                .lock()
                .expect("Unable to notify all joining threads");
            self.empty_condvar.notify_all();
        }
    }
}

has_work函数对工作的两个指示器进行了顺序一致性的读取，考虑到两个顺序一致性的读取，这个操作并不便宜，但暗示了对响应准确性的需求。no_work_notify_all函数更复杂、更神秘。幸运的是，该函数在Build::build的下一部分实现中使用了，这将有助于解开这个谜团。build的下一部分是：

        for _ in 0..num_threads {
            spawn_in_pool(shared_data.clone());
        }

        ThreadPool {
            jobs: tx,
            shared_data: shared_data,
        }
    }
}

对于每个num_threads，spawn_in_pool函数在Arced ThreadPoolSharedData的克隆上被调用。让我们检查spawn_in_pool：

fn spawn_in_pool(shared_data: Arc<ThreadPoolSharedData>) {
    let mut builder = thread::Builder::new();
    if let Some(ref name) = shared_data.name {
        builder = builder.name(name.clone());
    }
    if let Some(ref stack_size) = shared_data.stack_size {
        builder = builder.stack_size(stack_size.to_owned());
    }

如你所预期的那样，该函数创建 std::thread::Builder 并从 ThreadPoolSharedData 的共享数据中提取名称和堆栈大小的引用。有了这些变量，就调用 builder.spawn，以通常的方式传递一个闭包：

    builder
        .spawn(move || {
            // Will spawn a new thread on panic unless it is cancelled.
            let sentinel = Sentinel::new(&shared_data);

好吧，让我们来看看 Sentinel：

struct Sentinel<'a> {
    shared_data: &'a Arc<ThreadPoolSharedData>,
    active: bool,
}

它持有一个对 Arc<ThreadPoolSharedData> 的引用——避免增加引用计数——以及一个 active 布尔值。实现同样简洁：

impl<'a> Sentinel<'a> {
    fn new(shared_data: &'a Arc<ThreadPoolSharedData>) -> Sentinel<'a> {
        Sentinel {
            shared_data: shared_data,
            active: true,
        }
    }

    /// Cancel and destroy this sentinel.
    fn cancel(mut self) {
        self.active = false;
    }
}

这里的真正关键是 Drop 的实现：

impl<'a> Drop for Sentinel<'a> {
    fn drop(&mut self) {
        if self.active {
            self.shared_data.active_count.fetch_sub(1, Ordering::SeqCst);
            if thread::panicking() {
                self.shared_data.panic_count
                    .fetch_add(1, Ordering::SeqCst);
            }
            self.shared_data.no_work_notify_all();
            spawn_in_pool(self.shared_data.clone())
        }
    }
}

回想一下在上一节中，我们的连接向量无限制地增长，尽管那个向量中的线程已经恐慌并且不再工作。有一个接口可以确定当前线程是否处于恐慌状态，std::thread::panicking()，在这里被使用。

当一个线程发生恐慌时，它会丢弃其存储，在这个池中，这包括分配的 Sentinel。然后 drop 会检查 Sentinel 上的 active 标志，递减 ThreadPoolSharedData 的 active_count，增加其 panic_count，调用尚未神秘的 no_work_notify_all，然后向池中添加一个额外的线程。这样，池保持适当的大小，无需额外监控线程以确定何时需要回收：类型系统完成所有工作。

让我们回到 spawn_in_pool：

            loop {
                // Shutdown this thread if the pool has become smaller
                let thread_counter_val = shared_data
                                             .active_count
                                             .load(Ordering::Acquire);
                let max_thread_count_val = shared_data
                                             .max_thread_count
                                             .load(Ordering::Relaxed);
                if thread_counter_val >= max_thread_count_val {
                    break;
                }

在这里，我们可以看到 builder.spawn 函数无限循环的开始，以及一个检查，如果自上次循环迭代以来池的大小已减少，则关闭线程。ThreadPool 通过 set_num_threads 函数公开，允许在运行时更改池的大小。现在，为什么是无限循环呢？在某些系统上，创建新线程并不是一个完全快速的操作，而且，它不是免费的。如果你可以避免这种成本，你最好这样做。其他语言的某些池实现对于每个进入的工作都会创建一个新线程，担心内存污染。在 Rust 中，这个问题较小，因为不安全的内存访问必须有意为之，而 FnBox 由于闭包将没有对池的私有内存的指针，实际上是一个陷阱。循环存在是为了从 ThreadPoolSharedData 的接收器通道一侧拉取 Thunks：

                let message = {
                    // Only lock jobs for the time it takes
                    // to get a job, not run it.
                    let lock = shared_data
                        .job_receiver
                        .lock()
                        .expect("Worker thread unable to \
                                lock job_receiver");
                    lock.recv()
                };

消息可能是一个错误，这意味着 ThreadPool 被丢弃，关闭了发送器通道一侧。但是，如果消息是 Ok，我们将有要调用的 FnBox：

                let job = match message {
                    Ok(job) => job,
                    // The ThreadPool was dropped.
                    Err(..) => break,
                };

spawn_in_pool 的最后一部分并不引人注目：

                shared_data.active_count.fetch_add(1, Ordering::SeqCst);
                shared_data.queued_count.fetch_sub(1, Ordering::SeqCst);

                job.call_box();

                shared_data.active_count.fetch_sub(1, Ordering::SeqCst);
                shared_data.no_work_notify_all();
            }

            sentinel.cancel();
        })
        .unwrap();
}

FnBox 调用的作业是通过 call_box 来执行的，如果发生恐慌并杀死线程，Sentinel 会根据适当的情况清理原子引用，并在池中启动一个新的线程。通过依赖 Rust 的类型系统和内存模型，我们得到了一个廉价的线程池实现，它仅在需要时才创建线程，无需担心作业之间意外污染内存。

ThreadPool::execute 是对 FnOnce 的快速装箱，推送到 Thunk 通道的发送器一侧：

    pub fn execute<F>(&self, job: F)
    where
        F: FnOnce() + Send + 'static,
    {
        self.shared_data.queued_count.fetch_add(1, Ordering::SeqCst);
        self.jobs
            .send(Box::new(job))
            .expect("ThreadPool::execute unable to send job into queue.");
    }

这里最后一部分是 ThreadPool::join。这是 ThreadPoolSharedData::no_work_notify_all 开始发挥作用的地方。让我们看看 join：

    pub fn join(&self) {
        // fast path requires no mutex
        if self.shared_data.has_work() == false {
            return ();
        }

        let generation = self.shared_data
                             .join_generation
                             .load(Ordering::SeqCst);
        let mut lock = self.shared_data.empty_trigger.lock().unwrap();

        while generation == self.shared_data
                                .join_generation 
                                .load(Ordering::Relaxed)
            && self.shared_data.has_work()
        {
            lock = self.shared_data.empty_condvar.wait(lock).unwrap();
        }

        // increase generation if we are the first thread to
        // come out of the loop
        self.shared_data.join_generation.compare_and_swap(
            generation,
            generation.wrapping_add(1),
            Ordering::SeqCst,
        );
    }

函数首先调用 has_work，如果没有活跃或排队的线程在池中，就提前退出。在这里阻塞调用者没有理由。然后，generation 被设置为在 empty_condvar 周围的循环中充当条件变量。每个加入池的线程都会检查池的 generation 是否没有移动，这意味着其他线程尚未退出，并且还有工作要做。回想一下，是 no_work_notify_all 在条件变量上调用 notify_all，这个函数在 Sentinel 下降或 spawn_in_pool 的内部循环从任务返回时被调用。任何在这两个条件下醒来的已加入线程——任务完成或崩溃——都会检查它们的状态，在它们成为未加入状态的过程中增加 generation。

就这些！这是一个线程池，它是这本书到目前为止讨论的各个部分构建出来的。如果你想要创建一个没有队列的线程池，你可以在 execute 中添加一个额外的检查。一些顺序一致的原子操作可能也可以放宽，以及可能使简单实现更难推理的后果。如果你的执行任务非常简短，性能提升可能是值得的。实际上，我们将在本章后面讨论一个库，它提供了一个针对此类用例的替代线程池实现，尽管它比我们刚才讨论的要复杂得多。

以太网嗅探器

深入理解一项技术同样重要的是理解何时不应用它。让我们考虑另一个按工作单元划分的线程系统，但这次我们将回显以太网数据包，而不是通过 TCP 套接字接收到的行。我们项目的 Cargo.toml：

[package]
name = "sniffer"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
pnet = "0.21"

[[bin]]
name = "sniffer"

[[bin]]
name = "poor_threading"

就像 TCP 示例一样，我们将创建两个二进制文件，一个容易受到线程过载的影响——poor_threading——另一个——sniffer——则不会。这里的假设是我们想要嗅探网络接口的以太网数据包，反转该数据包的源和目标头，并将修改后的数据包发送回原始源。同时，我们将收集我们收集的数据包的摘要统计信息。在一个饱和的网络中，我们的小程序将会非常忙碌，并且必须在数据包丢失和接收方面做出权衡。

我们在这里引入的唯一依赖项是 pnet。libpnet 是一个低级数据包操作库，用于构建网络工具或进行传输协议的原型设计。我认为使用 libpnet 在通用网络设备上模糊测试传输实现非常有趣。不过，大多数情况下，回报是家庭路由器崩溃，但我觉得这很有趣。无论如何，让我们看看 poor_threading。它的前言相当平淡无奇：

extern crate pnet;

use pnet::datalink::Channel::Ethernet;
use pnet::datalink::{self, DataLinkReceiver, DataLinkSender, 
                     MacAddr, NetworkInterface};
use pnet::packet::ethernet::{EtherType, EthernetPacket, 
                             MutableEthernetPacket};
use pnet::packet::{MutablePacket, Packet};
use std::collections::HashMap;
use std::sync::mpsc;
use std::{env, thread};

我们引入了相当多的 pnet 功能，我们将在适当的时候进行讨论。我们不会引入 clap 或类似的参数解析库，而是要求用户将接口名称作为程序的第一个参数传入：

fn main() {
    let interface_name = env::args().nth(1).unwrap();
    let interface_names_match = |iface: &NetworkInterface| {
        iface.name == interface_name
    };

    // Find the network interface with the provided name
    let interfaces: Vec<NetworkInterface> = datalink::interfaces();
    let interface = interfaces
        .into_iter()
        .filter(interface_names_match)
        .next()
        .unwrap();

用户提供的接口名称将通过datalink::interfaces()函数与 pnet 能够找到的接口进行比对。尽管迭代器在本书中无处不在，并且被视为基本知识，但我们还没有在本书中深入探讨迭代器。不过，在之后我们将详细讨论 Rust 中的迭代。请注意，filter(interface_names_match)正在应用一个布尔函数interface_names_match(&NetworkInterface) -> bool到确定的接口的每个成员上。

如果函数返回 true，则成员通过过滤器，否则不通过。调用next().unwrap()将过滤迭代器向前推进一个项目，如果没有项目在过滤迭代器中，则会崩溃。这是一种对用户不太友好的方式来确定传递的接口实际上是否是 pnet 能够发现的接口。在我们的演示程序中这没问题。

接下来，我们为这个程序中的并发演员建立通信通道：

    let (snd, rcv) = mpsc::sync_channel(10);

    let _ = thread::spawn(|| gather(rcv));
    let timer_snd = snd.clone();
    let _ = thread::spawn(move || timer(timer_snd));

timer函数以固定间隔通过我们刚刚建立的通道推送时间脉冲，这与之前在本书中讨论的 cernan 所做的方式类似。该函数很小：

fn timer(snd: mpsc::SyncSender<Payload>) -> () {
    use std::{thread, time};
    let one_second = time::Duration::from_millis(1000);

    let mut pulses = 0;
    loop {
        thread::sleep(one_second);
        snd.send(Payload::Pulse(pulses)).unwrap();
        pulses += 1;
    }
}

Payload类型是一个只有两个变体的枚举：

enum Payload {
    Packet {
        source: MacAddr,
        destination: MacAddr,
        kind: EtherType,
    },
    Pulse(u64),
}

Pulse(u64)变体是定时器脉冲，由timer线程定期发送。在并发系统中将时间与实际的实际时钟分离非常有用，特别是在测试系统各个组件时。这对于将不同的消息变体统一到一个联合体中也有帮助。在撰写本文时，Rust 的 MPSC 实现还没有稳定的 select 功能，因此您必须手动使用mpsc::Receiver::recv_timeout和仔细的多路复用来实现它。将其统一到一个联合体类型中会更好。此外，这有助于类型系统站在您的这边，确认所有传入的变体都在单个 match 中处理，这也可能优化得更好。这种最后的好处应该进行衡量。

现在让我们看看gather：

fn gather(rcv: mpsc::Receiver<Payload>) -> () {
    let mut sources: HashMap<MacAddr, u64> = HashMap::new();
    let mut destinations: HashMap<MacAddr, u64> = HashMap::new();
    let mut ethertypes: HashMap<EtherType, u64> = HashMap::new();

    while let Ok(payload) = rcv.recv() {
        match payload {
            Payload::Pulse(id) => {
                println!("REPORT {}", id);
                println!("    SOURCES:");
                for (k, v) in sources.iter() {
                    println!("        {}: {}", k, v);
                }
                println!("    DESTINATIONS:");
                for (k, v) in destinations.iter() {
                    println!("        {}: {}", k, v);
                }
                println!("    ETHERTYPES:");
                for (k, v) in ethertypes.iter() {
                    println!("        {}: {}", k, v);
                }
            }
            Payload::Packet {
                source: src,
                destination: dst,
                kind: etype,
            } => {
                let mut destination = destinations.entry(dst).or_insert(0);
                *destination += 1;

                let mut source = sources.entry(src).or_insert(0);
                *source += 1;

                let mut ethertype = ethertypes.entry(etype).or_insert(0);
                *ethertype += 1;
            }
        }
    }
}

简单的接收器环路，提取Payload枚举。Payload::Packet变体被解构，其内容存储到三个HashMaps 中，将 MAC 地址映射到计数器或 EtherType 映射到计数器。MAC 地址是网络接口的唯一标识符——或者，理想情况下是唯一的，因为已经犯了一些错误——并在 OSI 模型的链路层中使用。（这不是一本关于网络的书，但我保证，这是一个非常有趣的领域。）EtherType 映射到每个以太网数据包开头的两个字节字段，定义了数据包的类型。有一个标准的类型列表，pnet 会为我们编码。当gather打印 EtherType 时，不需要做任何特殊的工作来获得可读的输出。

现在我们知道了gather和timer是如何工作的，我们可以结束main函数：

    let iface_handler = match datalink::channel(&interface, 
                                                Default::default()) {
        Ok(Ethernet(tx, rx)) => {
            let snd = snd.clone();
            thread::spawn(|| watch_interface(tx, rx, snd))
        }
        Ok(_) => panic!("Unhandled channel type"),
        Err(e) => panic!(
            "An error occurred when creating the datalink channel: {}",
            e
        ),
    };

    iface_handler.join().unwrap();
}

datalink::channel函数在给定的接口上建立了一个类似 MPSC 的通道，用于双向数据包的读取和写入。我们只关心以太网数据包，并且只匹配那个变体。我们为watch_interface创建了一个新线程，它接收通道的读写两侧以及为Payload创建的 MPSC。这样，我们有一个线程从网络读取以太网数据包，将它们剥离成标准化的Payload::Packet，并将它们推送到gather线程。同时，我们还有一个timer线程定期将Payload::Pulse推送到gather线程，以强制用户报告。

留意细节的读者会注意到我们的Payload通道实际上是sync_channel(10)，这意味着这个程序并不打算在内存中存储太多短暂的信息。在一个繁忙的以太网网络中，这意味着watch_interface可能无法将一个标准化的以太网数据包推送到通道。必须做些事情，而这完全取决于我们愿意失去多少信息。

让我们看看这个实现是如何处理这个问题的：

fn watch_interface(
    mut tx: Box<DataLinkSender>,
    mut rx: Box<DataLinkReceiver>,
    snd: mpsc::SyncSender<Payload>,
) {
    loop {
        match rx.next() {
            Ok(packet) => {
                let packet = EthernetPacket::new(packet).unwrap();

到目前为止，一切顺利。我们看到的是之前讨论过的datalink::Channel的侧面，以及我们的内部 MPSC。无限循环从通道的接收端读取&[u8]，我们的实现必须将其转换为正确的以太网数据包。如果我们非常彻底，我们会防范不完整的数据包，但由于我们不是，创建过程没有包裹。现在，关于将Payload::Packet标准化并传输到gather的过程：

                {
                    let payload: Payload = Payload::Packet {
                        source: packet.get_source(),
                        destination: packet.get_destination(),
                        kind: packet.get_ethertype(),
                    };
                    let thr_snd = snd.clone();
                    thread::spawn(move || {
                        thr_snd.send(payload).unwrap();
                    });
                }

哎呀。以太网数据包已经顺利地标准化为Payload::Packet，但当我们通过通道将数据包发送到gather时，我们是通过创建一个线程来做的。这里做出的决定是，不应该丢失任何传入的数据包——这意味着我们必须尽可能快地从网络接口读取它们——如果通道阻塞，我们需要将那个数据包存储在某个池中。

事实上，池是一个线程栈。或者，是一堆线程栈。即使我们在饱和网络中将线程的栈大小降低到一个合理的低值，我们最终还是会压倒操作系统。如果我们绝对不能忍受丢失包，我们可以使用例如 hopper (github.com/postmates/hopper)这样的工具，这在第五章中详细讨论了，锁——Mutex, Condvar, Barriers 和 RWLock，它是为这种用例设计的。或者，我们可以将这些发送推迟到线程池，允许它排队作业，并在有限数量的线程上运行。无论如何，让我们暂时放下这个问题，完成watch_interface：

                tx.build_and_send(1, packet.packet().len(), 
                                  &mut |new_packet| 
                {
                    let mut new_packet = 
                        MutableEthernetPacket::new(new_packet).unwrap();

                    // Create a clone of the original packet
                    new_packet.clone_from(&packet);

                    // Switch the source and destination
                    new_packet.set_source(packet.get_destination());
                    new_packet.set_destination(packet.get_source());
                });
            }
            Err(e) => {
                panic!("An error occurred while reading: {}", e);
            }
        }
    }
}

实现过程首先创建一个新的 EthernetPacket，然后在新的 EthernetPacket 中将原始的源地址和目标地址进行交换，并将它发送回原始的源地址。现在，让我们问问自己，我们是否真的需要统计从网络上可以提取的每一个 Ethernet 包？我们可以在gather线程中按照第二章中描述的方式，通过插入一个更快的哈希器来加速HashMap。或者，我们可以在同步通道满载时在watch_interface线程中进行缓冲，除了使用线程池或跳转器。仅仅加速gather和使用跳转器并不可能导致无界的存储需求。但是跳转器将需要一个文件系统，并且可能仍然无法接受所有传入的包，这只会使没有足够存储的可能性降低。

这是一个难题。考虑到第二层网络的本性，你不妨直接丢弃这些包。网卡本身就会丢弃包。考虑到这一点，本项目其他二进制文件sniffer中watch_interface的实现只有细微差别：

fn watch_interface(
    mut tx: Box<DataLinkSender>,
    mut rx: Box<DataLinkReceiver>,
    snd: mpsc::SyncSender<Payload>,
) {
    loop {
        match rx.next() {
            Ok(packet) => {
                let packet = EthernetPacket::new(packet).unwrap();

                let payload: Payload = Payload::Packet {
                    source: packet.get_source(),
                    destination: packet.get_destination(),
                    kind: packet.get_ethertype(),
                };
                if snd.try_send(payload).is_err() {
                    SKIPPED_PACKETS.fetch_add(1, Ordering::Relaxed);
                }

创建了Payload::Packet，而不是调用snd.send，这个实现调用snd.try_send，在需要丢弃包的情况下增加一个SKIPPED_PACKETS静态AtomicUsize。收集实现也相应地进行了轻微调整，以报告这个新的SKIPPED_PACKETS：

fn gather(rcv: mpsc::Receiver<Payload>) -> () {
    let mut sources: HashMap<MacAddr, u64> = HashMap::new();
    let mut destinations: HashMap<MacAddr, u64> = HashMap::new();
    let mut ethertypes: HashMap<EtherType, u64> = HashMap::new();

    while let Ok(payload) = rcv.recv() {
        match payload {
            Payload::Pulse(id) => {
                println!("REPORT {}", id);
                println!(
                    "    SKIPPED PACKETS: {}",
                    SKIPPED_PACKETS.swap(0, Ordering::Relaxed)
                );

这个程序将使用适度的存储量用于Payload通道，无论网络有多忙。

在高流量域或长期部署中，gather线程中的HashMap将是一个问题，但这是一个勇敢的读者被邀请解决的问题。

当你运行sniffer时，你应该得到非常类似于这样的输出：

REPORT 6
    SKIPPED PACKETS: 75
    SOURCES:
        ff:ff:ff:ff:ff:ff: 1453
        00:23:6a:00:51:6e: 2422
        5c:f9:38:8b:4a:b6: 1034
    DESTINATIONS:
        33:33:ff:0b:62:e8: 1
        33:33:ff:a1:90:82: 1
        33:33:00:00:00:01: 1
        00:23:6a:00:51:6e: 2414
        5c:f9:38:8b:4a:b6: 1032
        ff:ff:ff:ff:ff:ff: 1460
    ETHERTYPES:
        Ipv6: 4
        Ipv4: 1999
        Arp: 2906

这个报告来自我的sniffer运行的第 6 秒，由于存储不足，丢弃了 75 个包。这比 75 个线程要好。

迭代器

到目前为止，我们假设读者至少对 Rust 迭代器有初步的了解。可能你已经广泛地使用了它们，但从未编写过自己的迭代器实现。这些知识对于接下来的内容很重要，现在我们将讨论 Rust 的迭代功能。

Rust 迭代器是任何实现了 std::iter::Iterator 的类型。Iterator 特质有一个内部的 Item 类型，这使得熟悉的迭代器函数，如 next(&mut self) -> Option<Self::Item>，可以基于那个泛型 Item 来定义。许多迭代器函数在本质上都是函数式的：map、filter 和 fold 都是 Item 流上的高阶函数。许多迭代器函数是对那个 Item 流的搜索：max、min、position 和 find。这是一个多才多艺的特质。如果你觉得它在某些方面有限，社区已经整理了一个具有更多功能的 crate：itertools (crates.io/crates/itertools)。在这里，我们更关注的是如何为我们自己的类型实现它，而不是 Iterator 的接口。

Smallcheck 迭代

在 第二章，顺序 Rust 性能和测试，第五章，锁 – Mutex、Condvar、屏障和 RWLock，以及 第六章，原子操作 – 同步的原始操作，我们讨论了 QuickCheck 测试方法，一种将随机、类型驱动的输入插入函数中以搜索函数属性故障的结构化方法。受 Claessen 和 Hughes 在他们的 QuickCheck 论文中所做工作的启发，Runciman、Naylor 和 Lindblad 观察到，根据他们的经验，大多数故障都出现在小输入上，并提出了一个观察：一个从小输出到大输出的测试库可能会比纯随机方法更快地找到故障。他们的假设在某个函数域中大致是正确的，但这种方法存在重复劳动的问题，作者在相同的论文中通过 Lazy Smallcheck 部分地解决了这个问题。我们不会在这里进一步详细讨论，但论文包含在本章的 进一步阅读 部分，并鼓励读者查阅这篇论文。

无论如何，生成一个从 小 到 大 的类型的所有值听起来像是迭代。事实上，它就是。让我们看看如何为有符号和无符号整数生成迭代器。项目的 Cargo.toml 是最简的：

[package]
name = "smalliters"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]

无依赖，仅使用 cargo new 默认创建的内容。项目只有一个文件，src/lib.rs。接下来的讨论将在这个文件上下文中进行。首先，是前言：

use std::iter::Iterator;
use std::mem;

我们引入了 Iterator，正如你所预期的，然后是 std::mem，这是我们在这本书中看到过的。这里没有什么不寻常的。对于这本书来说，不寻常的是：

macro_rules! unsized_iter {
    ($name:ident, $int:ty, $max:expr) => {

一个宏！我们在整本书中一直在使用宏，但还没有编写过一个。Rust 中的宏有点像一门黑暗的艺术，而且有点让人烦躁，但一旦工作起来就很好。我们的目标很简单。Rust 整数类型的迭代器大部分相同，不同之处在于有符号/无符号和类型的总位数，因此使用 std::mem。($name:ident, $int:ty, and $max:expr) 声明三个宏变量：$name 是一个标识符，$int 是一个类型，$max 是一个表达式。以下是我们将如何使用 unsigned_iter! 宏：

unsized_iter!(SmallU8, u8, u8::max_value());
unsized_iter!(SmallU16, u16, u16::max_value());
unsized_iter!(SmallU32, u32, u32::max_value());
unsized_iter!(SmallU64, u64, u64::max_value());
unsized_iter!(SmallUsize, usize, usize::max_value());

那是一个标识符，后面跟着一个类型，然后是一个表达式。好的，现在回到宏定义：

macro_rules! unsized_iter {
    ($name:ident, $int:ty, $max:expr) => {
        #[derive(Default)]
        pub struct $name {
            cur: $int,
            done: bool,
        }

定义整数类型的小迭代器的第一步是生成一个结构体来存储迭代器实现所需的数据。我们需要两样东西，当前的整数和一个布尔标志来告诉我们何时迭代完成。当宏展开时，展开的源代码中将有名为 SmallU8、SmallU16 等的结构体，如下所示：

#[derive(Default)]
pub struct SmallU8 {
    cur: u8,
    done: bool,
}

无符号类型的 Iterator 实现很简单：持续增加直到达到类型的最大值：

        impl Iterator for $name {
            type Item = $int;

            fn next(&mut self) -> Option<$int> {
                if self.done {
                    return None;
                }
                let old = self.cur;
                if old == $max {
                    self.done = true;
                }
                self.cur = self.cur.saturating_add(1);
                return Some(old);
            }

从技术上讲，saturating_add 不是必需的，可以用 += 替换，但为了避免环绕错误，这样做是有帮助的。最后，我们还提供了一个 Iterator::size_hint 实现：

            fn size_hint(&self) -> (usize, Option<usize>) {
                let size = mem::size_of::<$int>() * 8;
                let total = 2_usize.pow(size as u32);
                let remaining = total - (self.cur as usize);
                (remaining, Some(remaining))
            }
        }
    };
}

这个函数是一个可选实现，但提供一个是友好的。返回的元组估计迭代中剩余的项目数量，第一个元素是下限估计，第二个是可选的上限。我们恰好知道剩余要迭代的元素数量，因为我们的域是有限的。实现 Iterator::size_hint 将有助于代码预分配缓冲区，这包括 Iterator 上的其他函数。

有大小整数类型有类似的实现。它们使用的宏 sized_iter! 如下所示：

sized_iter!(SmallI8, i8, i8::min_value());
sized_iter!(SmallI16, i16, i16::min_value());
sized_iter!(SmallI32, i32, i32::min_value());
sized_iter!(SmallI64, i64, i64::min_value());
sized_iter!(SmallIsize, isize, isize::min_value());

宏本身开始的方式与它的无符号对应物相同：

macro_rules! sized_iter {
    ($name:ident, $int:ty, $min:expr) => {
        #[derive(Default)]
        pub struct $name {
            cur: $int,
            done: bool,
        }

        impl Iterator for $name {
            type Item = $int;

            fn next(&mut self) -> Option<$int> {
                if self.done {
                    return None;
                }

只有 next 的内部部分不同：

                let old = self.cur;
                if self.cur == 0 {
                    self.cur = -1;
                } else if self.cur.is_negative() && self.cur == $min {
                    self.done = true;
                } else if self.cur.is_positive() {
                    self.cur *= -1;
                    self.cur -= 1;
                } else if self.cur.is_negative() {
                    self.cur *= -1;
                }
                return Some(old);
            }

这需要一些解释。我们从 SmallCheck 论文中获得灵感，并按如下方式迭代值：0，-1，1，-2，2，依此类推。实现可以遵循与无符号变体相同的方法，从 min_value() 到 max_value() 递增，但这不会是小到大的，至少在字节表示方面。最后，size_hint：

            fn size_hint(&self) -> (usize, Option<usize>) {
                let size = mem::size_of::<$int>() * 8;
                let total = 2_usize.pow(size as u32);
                let remaining = total - ((self.cur.abs() * 2) as usize);
                (remaining, Some(remaining))
            }
        }
    };
}

如果这些实现正确无误，我们新迭代器的 Iterator::count 应该等于类型位大小的两倍，count 是一个记录迭代元素数量的函数。测试还依赖于宏来减少重复。首先，有符号变体：

#[cfg(test)]
mod tests {
    use super::*;

    macro_rules! sized_iter_test {
        ($test_name:ident, $iter_name:ident, $int:ty) => {
            #[test]
            fn $test_name() {
                let i = $iter_name::default();
                let size = mem::size_of::<$int>() as u32;
                assert_eq!(i.count(), 2_usize.pow(size * 8));
            }
        };
    }

    sized_iter_test!(i8_count_correct, SmallI8, i8);
    sized_iter_test!(i16_count_correct, SmallI16, i16);
    sized_iter_test!(i32_count_correct, SmallI32, i32);
    // NOTE: These take forever. Uncomment if you have time to burn.
    // sized_iter_test!(i64_count_correct, SmallI64, i64);
    // sized_iter_test!(isize_count_correct, SmallIsize, isize);

现在是无符号变体：

    macro_rules! unsized_iter_test {
        ($test_name:ident, $iter_name:ident, $int:ty) => {
            #[test]
            fn $test_name() {
                let i = $iter_name::default();
                let size = mem::size_of::<$int>() as u32;
                assert_eq!(i.count(), 2_usize.pow(size * 8));
            }
        };
    }

    unsized_iter_test!(u8_count_correct, SmallU8, u8);
    unsized_iter_test!(u16_count_correct, SmallU16, u16);
    unsized_iter_test!(u32_count_correct, SmallU32, u32);
    // NOTE: These take forever. Uncomment if you have time to burn.
    // unsized_iter_test!(u64_count_correct, SmallU64, u64);
    // unsized_iter_test!(usize_count_correct, SmallUsize, usize);
}

如果您运行测试，应该会发现它们都通过了。对于较大的类型，可能需要一分钟。但，这些都是迭代器。它们只是某种基本类型——在本例中是内置整数——加上一个状态跟踪类型——我们的Small*结构体——以及该状态跟踪类型的Iterator实现。非常有用，并且优化器相当擅长将迭代器链转换为循环，并且在这方面越来越擅长。

rayon – 并行迭代器

在上一节中，我们构建了一个 Rust 整数类型的迭代器。每次next调用的基本计算很小——一些分支检查，可能还有取反或加法操作。如果我们尝试并行化这个操作，操作系统分配新线程所需的时间将会淹没任何潜在的性能提升。无论这变得多快，它仍然会比加法操作慢。但是，如果我们全力以赴地以迭代风格编写代码，并且确实有一些可以从并行运行中受益的计算，那么我们如何使std::iter::Iterator并行化呢？

您使用 rayon。

rayon crate 是一个 Rust 的数据并行库。也就是说，它扩展了 Rust 的基本Iterator概念，包括隐式并行的概念。是的，隐式。Rust 的内存安全性意味着我们可以在现代机器上玩一些相当有趣的花招。考虑一下我们在本章之前调查的线程池实现，它对内存污染没有顾虑。好吧，rayon 也是同样的情况。迭代器中的每个元素都是相互隔离的，这是类型系统强制执行的不变性质。这意味着，rayon 的开发者可以专注于构建尽可能快的并行库，而我们，作为最终用户，可以专注于以迭代器风格结构化我们的代码。

我们将检查 SHA 5f98c019abc4d40697e83271c072cb2b92966f46下的 rayon (crates.io/crates/rayon)。rayon 项目被拆分为子 crate：

• rayon-core

• rayon-futures

在本章中，我们将讨论 rayon（顶级 crate）和 rayon-core，并在第十章[2dc30216-c606-471f-a94a-dc4891a0cb1b.xhtml]的“未来主义——近期 Rust”中涉及 rayon-futures 背后的基本技术。感兴趣的读者可以标记 rayon-futures 来尝试该接口，但请务必参考该子 crate 顶部的README以获取详细信息。

rayon crate 的完整列表并未列出。您可以在本书的源代码仓库中找到完整的列表。

rayon 的依赖项最少，因为 rayon-core 默认是唯一依赖项。rayon-core 的依赖项包括：

[dependencies]
rand = ">= 0.3, < 0.5"
num_cpus = "1.2"
libc = "0.2.16"
lazy_static = "1"

我们之前已经见过这些依赖项，除了libc。这个库通过稳定的接口暴露了libc平台。根据项目的文档：

"这个 crate 并不追求跨平台的任何形式的兼容性，而是简单地直接绑定到特定平台的系统库。"

这非常有用。现在，rayon 是一个大型库，导航可能是一个挑战。不过，没关系，因为它使用起来很简单。为了给自己一个切入点，让我们从 rayon 的 README 中提取示例代码，并从这个点开始探索。示例是：

use rayon::prelude::*;

fn sum_of_squares(input: &[i32]) -> i32 {
    input.par_iter()
         .map(|&i| i * i)
         .sum()
}

好的，这里发生了什么？好吧，让我们首先将它与这个示例的顺序版本进行比较：

fn sum_of_squares(input: &[i32]) -> i32 {
    input.iter()
         .map(|&i| i * i)
         .sum()
}

找到关键的区别了吗？顺序版本是 input.iter()，并行版本是 input.par_iter()。好吧，首先，我们必须理解每个切片都暴露了 iter(&self) -> std::slice::Iter。这个 Iter 实现了 std::iter::Iterator，这是我们最近讨论过的。rayon 实现了类似的东西，所以：

• input.iter() :: std::slice::Iter<'_, u32>

• input.par_iter() :: rayon::slice::Iter<'_, i32>

让我们看看 rayon::slice::Iter，在 src/slice/mod.rs 中：

#[derive(Debug)]
pub struct Iter<'data, T: 'data + Sync> {
    slice: &'data [T],
}

好的，我们之前都见过。这里有一份终身数据，每个 T 都必须是终身数据的一部分加上 Sync。现在，射线 map 的类型是什么？通过检查，我们可以看到它是 ParallelIterator::map<F, R>(self, map_op: F) -> Map<Self, F>，其中 F: Fn(Self::Item) -> R + Sync + Send 和 R: Send。好的，ParallelIterator。这是新的。在结构定义下方有一个 Iter 的实现：

impl<'data, T: Sync + 'data> ParallelIterator for Iter<'data, T> {
    type Item = &'data T;

    fn drive_unindexed<C>(self, consumer: C) -> C::Result
        where C: UnindexedConsumer<Self::Item>
    {
        bridge(self, consumer)
    }

    fn opt_len(&self) -> Option<usize> {
        Some(self.len())
    }
}

显然，我们需要理解 ParallelIterator。这个特质在 src/iter/mod.rs 中定义，并声明为标准迭代特质的一个并行版本。太好了！这给了我们一个很好的语义锚点。现在，我们只需要弄清楚它的实现。ParallelIterator 对 Iter 的实现定义了两个函数：drive_unindexed 和 opt_len。后者函数返回底层结构的可选长度，就像 Iterator::size_hint 一样。

rayon 文档指出，他们的某些函数在 opt_len 返回一个值时可以触发快速路径：总是赢。drive_unindexed 更复杂，引入了两个未知数。首先，我们来弄清楚 consumer: UnindexedConsumer 是什么。在 src/iter/plumbing/mod.rs 中的特质定义非常简短：

pub trait UnindexedConsumer<I>: Consumer<I> {
    /// Splits off a "left" consumer and returns it. The `self`
    /// consumer should then be used to consume the "right" portion of
    /// the data. (The ordering matters for methods like find_first –
    /// values produced by the returned value are given precedence
    /// over values produced by `self`.) Once the left and right
    /// halves have been fully consumed, you should reduce the results
    /// with the result of `to_reducer`.
    fn split_off_left(&self) -> Self;

    /// Creates a reducer that can be used to combine the results from
    /// a split consumer.
    fn to_reducer(&self) -> Self::Reducer;
}

好的，我们这里缺少一些关键信息。什么是 Consumer？这个特质在同一个文件中定义，如下所示：

pub trait Consumer<Item>: Send + Sized {
    /// The type of folder that this consumer can be converted into.
    type Folder: Folder<Item, Result = Self::Result>;

    /// The type of reducer that is produced if this consumer is split.
    type Reducer: Reducer<Self::Result>;

    /// The type of result that this consumer will ultimately produce.
    type Result: Send;

    /// Divide the consumer into two consumers, one processing items
    /// `0..index` and one processing items from `index..`. Also
    /// produces a reducer that can be used to reduce the results at
    /// the end.
    fn split_at(self, index: usize) -> (Self, Self, Self::Reducer);

    /// Convert the consumer into a folder that can consume items
    /// sequentially, eventually producing a final result.
    fn into_folder(self) -> Self::Folder;

    /// Hint whether this `Consumer` would like to stop processing
    /// further items, e.g. if a search has been completed.
    fn full(&self) -> bool;
}

这里有一些关键未知数，但画面变得稍微清晰了一些。Consumer 能够接收 Item 并在 index 处将其细分。rayon 正在进行分而治之，将流的小块划分到 某个东西 上。Folder 和 Reducer 是什么？这个特质 折叠 到自身，就像高阶折叠函数一样。特质定义如下：

pub trait Folder<Item>: Sized {
    type Result;

    fn consume(self, item: Item) -> Self;

    fn consume_iter<I>(mut self, iter: I) -> Self
        where I: IntoIterator<Item = Item>
    {
        for item in iter {
            self = self.consume(item);
            if self.full() {
                break;
            }
        }
        self
    }

    fn complete(self) -> Self::Result;

    fn full(&self) -> bool;
}

这里重要的函数是 consume_iter。注意它为 iter 变量中的每个元素调用 consume，将前一个 self 折叠成一个新的 self，直到 Folder 的实现者表示它已经 满了。同时请注意，一旦 Folder 完成，就会对其调用，并将其转换为 Result。回想一下，Result 是在 Consumer 中设置的。现在，什么是 Reducer？它是：

pub trait Reducer<Result> {
    fn reduce(self, left: Result, right: Result) -> Result;
}

Reducer 将两个 Result 合并成一个单一的 Result。然后 Consumer 是一种可以接受一个 Item，对 Item 的块应用 Folder，然后将多个 Result 简化成一个单一的 Result 的类型。如果你眯起眼睛看，Consumer 实际上 是一个折叠操作。UnindexedConsumer 是 Consumer 的一个特殊化，它在任意点分割，而普通的 Consumer 需要一个索引。因此，我们理解到切片迭代器的并行迭代器是由 drive_unindexed 驱动的。这个函数传递了 一些 consumer: C，其中 C 至少是 UnindexedConsumer，并且函数完全委托给 bridge 来完成其工作。有两个问题：谁 调用了 drive_unindexed，以及 bridge 是什么？让我们来看看定义在 src/iter/plumbing/mod.rs 中的 bridge 函数。函数的头部立即提供了新的信息：

pub fn bridge<I, C>(par_iter: I, consumer: C) -> C::Result
    where I: IndexedParallelIterator,
          C: Consumer<I::Item>

什么是 IndexedParallelIterator？我将省略探索过程，但它是 ParallelIterator 的进一步特殊化，可以在 任意索引处 分割。这种特殊化比 ParallelIterator 特性有更多函数，rayon::slice::Iter 实现了这两个。定义简短，但我们需要了解以理解 bridge：

impl<'data, T: Sync + 'data> IndexedParallelIterator for Iter<'data, T> {
    fn drive<C>(self, consumer: C) -> C::Result
        where C: Consumer<Self::Item>
    {
        bridge(self, consumer)
    }

    fn len(&self) -> usize {
        self.slice.len()
    }

    fn with_producer<CB>(self, callback: CB) -> CB::Output
        where CB: ProducerCallback<Self::Item>
    {
        callback.callback(IterProducer { slice: self.slice })
    }
}

我们看到 bridge 支持一个 drive 函数和一个具有未知目的的新 with_producer 函数。回到 bridge：

{
    let len = par_iter.len();
    return par_iter.with_producer(Callback {
                                      len: len,
                                      consumer: consumer,
                                  });

我们看到 bridge 计算底层切片的长度，然后在一个 Callback 结构体上调用 with_producer。我们知道从 Iter 的特实现中，Callback: ProducerCallback，它本身类似于 FnOnce，接受一些 T，一个 Producer<T>，并从 ProducerCallback::callback 发出一个 Output。如果你足够眯起眼睛，那就是一个闭包。Producer 大概相当于 std::iter::IntoIterator，但它可以在索引处分割成两个 Producer。再次，我们看到 rayon 正在将工作分割成子任务，并且这种操作方法贯穿多个类型。但 Callback 是什么呢？实际上，这个结构体是与 bridge 函数的函数体一起内联定义的：

    struct Callback<C> {
        len: usize,
        consumer: C,
    }

    impl<C, I> ProducerCallback<I> for Callback<C>
        where C: Consumer<I>
    {
        type Output = C::Result;
        fn callback<P>(self, producer: P) -> C::Result
            where P: Producer<Item = I>
        {
            bridge_producer_consumer(self.len, producer, self.consumer)
        }
    }
}

我承认，这相当奇怪！内部回调中传递的 producer: P 是一个 IterProducer，这是一个在 src/slice/mod.rs 中定义的类型，它持有切片的引用。有趣的是 Producer 对 IterProducer 的实现：

impl<'data, T: 'data + Sync> Producer for IterProducer<'data, T> {
    type Item = &'data T;
    type IntoIter = ::std::slice::Iter<'data, T>;

    fn into_iter(self) -> Self::IntoIter {
        self.slice.into_iter()
    }

    fn split_at(self, index: usize) -> (Self, Self) {
        let (left, right) = self.slice.split_at(index);
        (IterProducer { slice: left }, IterProducer { slice: right })
    }
}

看那个 split_at！每当 rayon 需要分割一个切片生产者时，它会调用 std::slice::split_at 并创建两个新的 Producer。好吧，现在我们知道了 rayon 是如何分割事物的，但仍然不知道 分割到什么程度。让我们进一步了解 bridge_producer_consumer 的实现：

pub fn bridge_producer_consumer<P, C>(len: usize, producer: P,
                                      consumer: C) -> C::Result
    where P: Producer,
          C: Consumer<P::Item>
{
    let splitter = LengthSplitter::new(producer.min_len(), 
                                       producer.max_len(), len);
    return helper(len, false, splitter, producer, consumer);

好吧，我们大多数人对这些类型都很熟悉。LengthSplitter 是新的，它是一种类型，告诉我们某个长度的分割对于某些最小大小是否有效。这就是 rayon 能够决定分割工作的大小以及是否进一步分割工作负载的地方。helper 函数使一切完整：

    fn helper<P, C>(len: usize,
                    migrated: bool,
                    mut splitter: LengthSplitter,
                    producer: P,
                    consumer: C)
                    -> C::Result
        where P: Producer,
              C: Consumer<P::Item>
    {
        if consumer.full() {
            consumer.into_folder().complete()
        } else if splitter.try(len, migrated) {
            let mid = len / 2;
            let (left_producer, right_producer) = producer.split_at(mid);
            let (left_consumer, right_consumer, 
                 reducer) = consumer.split_at(mid);
            let (left_result, right_result) =
                join_context(|context| {
                    helper(mid, context.migrated(), splitter,
                           left_producer, left_consumer)
                }, |context| {
                    helper(len - mid, context.migrated(), splitter,
                           right_producer, right_consumer)
                });
            reducer.reduce(left_result, right_result)
        } else {
            producer.fold_with(consumer.into_folder()).complete()
        }
    }
}

这很密集。大部分都是为了将当前的 Producer 分割成适当大小的块，但特别是这段代码：

                join_context(|context| {
                    helper(mid, context.migrated(), splitter,
                           left_producer, left_consumer)
                }, |context| {
                    helper(len - mid, context.migrated(), splitter,
                           right_producer, right_consumer)
                });

在这里，我们看到新分割的 Producers 在由 join_context 执行时会懒加载地递归调用 helper。这个函数定义在 rayon-core/src/join/mod.rs 中：

pub fn join_context<A, B, RA, RB>(oper_a: A, oper_b: B) -> (RA, RB)
    where A: FnOnce(FnContext) -> RA + Send,
          B: FnOnce(FnContext) -> RB + Send,
          RA: Send,
          RB: Send
{

这里的新类型 FnContext 是一个 Send + Sync 禁用布尔值。FnContext 内部的布尔值被称为 migrated，这是一个关于上下文目的的有趣线索。让我们继续在 join_context 中：

    registry::in_worker(|worker_thread, injected| unsafe {
        log!(Join { worker: worker_thread.index() });

        // Create virtual wrapper for task b; this all has to be
        // done here so that the stack frame can keep it all live
        // long enough.
        let job_b = StackJob::new(|migrated| 
                                  oper_b(FnContext::new(migrated)),
                                  SpinLatch::new());
        let job_b_ref = job_b.as_job_ref();
        worker_thread.push(job_b_ref);

嗨，这是一个线程池！我们 知道 线程池！与我们在本章早期调查的线程池实现相比，rayon 的线程池实现有更多细节，但它是一个已知的概念。rayon 池中的每个线程都维护自己的工作队列。每个线程都会排队两个新的工作——在这种情况下，调用具有特定 FnContext 的 helper 函数——这些函数可能执行 Consumer 和 Producer 合并表示的函数，或者将工作分割成小块，推送到线程的队列中。池中的每个线程都能够从其他线程中窃取工作，将负载分散到池中。实际上，我们到目前为止看到的是，join_context 的调用者立即从 oper_b 构造 StackJob 并调用 worker_thread.push。这个函数定义在 rayon-core/src/registry.rs 中：

    #[inline]
    pub unsafe fn push(&self, job: JobRef) {
        self.worker.push(job);
        self.registry.sleep.tickle(self.index);

sleep.tickle 除了名字有趣之外，还旨在通知等待在 condvar 上的线程。这个 condvar 跟踪是否有可用的任务，当没有任务时节省电力，而不是让线程在池中空转。当调用 self.worker.push 时会发生什么？结果是，WorkerThread::worker 字段是 crossbeam_deque::Deque<job::JobRef> 类型。我们在上一章讨论了 crossbeam！事情开始对我们有好处。让我们看看 WorkerThread 的定义：

pub struct WorkerThread {
    /// the "worker" half of our local deque
    worker: Deque<JobRef>,

    index: usize,

    /// are these workers configured to steal breadth-first or not?
    breadth_first: bool,

    /// A weak random number generator.
    rng: UnsafeCell<rand::XorShiftRng>,

    registry: Arc<Registry>,
}

什么是 Registry？什么在创建这些 WorkerThreads？回想一下，在 join_context 中，我们处于 registry::in_worker 调用内部。这个函数定义在 rayon-core/src/registry.rs 中，并且是：

pub fn in_worker<OP, R>(op: OP) -> R
    where OP: FnOnce(&WorkerThread, bool) -> R + Send, R: Send
{
    unsafe {
        let owner_thread = WorkerThread::current();
        if !owner_thread.is_null() {
            // Perfectly valid to give them a `&T`: this is the
            // current thread, so we know the data structure won't be
            // invalidated until we return.
            op(&*owner_thread, false)
        } else {
            global_registry().in_worker_cold(op)
        }
    }
}

WorkerThread::current() 调用正在轮询一个名为 WORKER_THREAD_STATE 的线程局部静态变量，它是一个 Cell<*const WorkerThread>，在当前操作系统线程中尚未创建 WorkerThread 或由于某些原因已停止存在的情况下，可能为空。如果 WorkerThread 作为线程局部存在，则调用传递的 op 函数，这就是我们在 join_context 中调查的内容。但是，如果线程局部为空，则调用 global_registry().in_worker_cold(op)。global_registry 是：

static mut THE_REGISTRY: Option<&'static Arc<Registry>> = None;
static THE_REGISTRY_SET: Once = ONCE_INIT;

/// Starts the worker threads (if that has not already happened). If
/// initialization has not already occurred, use the default
/// configuration.
fn global_registry() -> &'static Arc<Registry> {
    THE_REGISTRY_SET.call_once(|| unsafe { init_registry(ThreadPoolBuilder::new()).unwrap() });
    unsafe { 
        THE_REGISTRY.expect("The global thread pool \
                            has not been initialized.") 
    }
}

即，一旦至少调用一次 global_registry()，我们就已经建立了一个由 init_registry 返回值填充的静态 Registry：

unsafe fn init_registry(builder: ThreadPoolBuilder) -> Result<(), ThreadPoolBuildError> {
    Registry::new(builder).map(|registry| 
                                THE_REGISTRY = Some(leak(registry))
                              )
}

该函数在填充了一些用于配置的构建器之后进一步委托给 Registry::new：

impl Registry {
    pub fn new(mut builder: ThreadPoolBuilder) 
           -> Result<Arc<Registry>, ThreadPoolBuildError> 
    {
        let n_threads = builder.get_num_threads();
        let breadth_first = builder.get_breadth_first();

        let inj_worker = Deque::new();
        let inj_stealer = inj_worker.stealer();
        let workers: Vec<_> = (0..n_threads)
            .map(|_| Deque::new())
            .collect();
        let stealers: Vec<_> = workers.iter().map(|d| 
                                                  d.stealer()
                                              ).collect();

        let registry = Arc::new(Registry {
            thread_infos: stealers.into_iter()
                .map(|s| ThreadInfo::new(s))
                .collect(),
            state: Mutex::new(RegistryState::new(inj_worker)),
            sleep: Sleep::new(),
            job_uninjector: inj_stealer,
            terminate_latch: CountLatch::new(),
            panic_handler: builder.take_panic_handler(),
            start_handler: builder.take_start_handler(),
            exit_handler: builder.take_exit_handler(),
        });

这里，终于，我们看到线程正在被构建：

        // If we return early or panic, make sure to terminate 
        // existing threads.
        let t1000 = Terminator(&registry);

        for (index, worker) in workers.into_iter().enumerate() {
            let registry = registry.clone();
            let mut b = thread::Builder::new();
            if let Some(name) = builder.get_thread_name(index) {
                b = b.name(name);
            }
            if let Some(stack_size) = builder.get_stack_size() {
                b = b.stack_size(stack_size);
            }
            if let Err(e) = b.spawn(move || unsafe { 
                main_loop(worker, registry, index, breadth_first) 
            }) {
                return Err(ThreadPoolBuildError::new(
                               ErrorKind::IOError(e))
                           )
            }
        }

        // Returning normally now, without termination.
        mem::forget(t1000);

        Ok(registry.clone())
    }

哇！好吧，一个 Registry 是一个静态变量，一旦创建，就会启动多个线程并将它们进入 main_loop。这个循环创建 WorkerThread，通知 Registry WorkerThread 已启动，这标志着线程处于活动状态。这是 Registry 的 thread_infos，也是为什么 WorkerThread 在其自身中携带索引的原因。main_thread 调用 WorkerThread::wait_until，这是一个用于探测 Registry 是否有终止通知的函数，如果没有该通知，则调用 WorkerThread::wait_until_cold。这种冷状态是 WorkerThread 在 take_local_job 或窃取失败无法返回任何项目时的状态。获取本地工作的样子如下：

    #[inline]
    pub unsafe fn take_local_job(&self) -> Option<JobRef> {
        if !self.breadth_first {
            self.worker.pop()
        } else {
            loop {
                match self.worker.steal() {
                    Steal::Empty => return None,
                    Steal::Data(d) => return Some(d),
                    Steal::Retry => {},
                }
            }
        }
    }

这里的 self.worker 是来自 crossbeam 的双端队列，而广度优先选项仅控制从双端队列的哪一端检索工作。窃取要复杂一些，使用 WorkerThread 的随机数生成器来选择任意线程——通过 Registry 索引——从其那里窃取工作，向前遍历线程，直到可以从另一个线程的双端队列中窃取工作或直到找不到任何工作。

没有更多的神秘了！当我们进一步深入 rayon 时，我们了解到它拥有相当多的机制来表示分割的工作负载，然后这些工作负载逐渐过渡到在线程池上执行这些工作块。这个线程池执行工作窃取以保持 CPU 满载。这种理解有助于使 join_context 的其余部分更容易理解：

        // Execute task a; hopefully b gets stolen in the meantime.
        let status_a = unwind::halt_unwinding(move || 
                           oper_a(FnContext::new(injected)));
        let result_a = match status_a {
            Ok(v) => v,
            Err(err) => join_recover_from_panic(worker_thread, 
                                                &job_b.latch, 
                                                err),
        };

join_context 的调用者将 oper_b 打包，推送到工作队列，并执行 oper_a，希望其他操作也能被执行。函数的其余部分是一个循环，要么从本地双端队列中拉取 oper_b，要么从其他线程中窃取：

        while !job_b.latch.probe() {
            if let Some(job) = worker_thread.take_local_job() {
                if job == job_b_ref {
                    // Found it! Let's run it.
                    //
                    // Note that this could panic, but it's ok if we 
                    // unwind here.
                    log!(PoppedRhs { worker: worker_thread.index() });
                    let result_b = job_b.run_inline(injected);
                    return (result_a, result_b);
                } else {
                    log!(PoppedJob { worker: worker_thread.index() });
                    worker_thread.execute(job);
                }
            } else {
                // Local deque is empty. Time to steal from other
                // threads.
                log!(LostJob { worker: worker_thread.index() });
                worker_thread.wait_until(&job_b.latch);
                debug_assert!(job_b.latch.probe());
                break;
            }
        }

        return (result_a, job_b.into_result());
    })

通过锁机制维护顺序，该机制在 rayon-core/src/latch.rs 中定义。鼓励您研究这一机制。它非常巧妙，对于已经阅读到此书的读者来说，完全在理解能力范围内，祝福您。

这几乎就是全部了。我们还没有讨论 map(|&i| i * i).sum()。那里的 map 定义在 ParallelIterator、IndexedParallelIterator 上，并且是：

    fn map<F, R>(self, map_op: F) -> Map<Self, F>
        where F: Fn(Self::Item) -> R + Sync + Send,
              R: Send
    {
        map::new(self, map_op)
    }

Map 是一个 ParallelIterator，它消费单个 map_op 函数，并从中产生 MapConsumer，其细节我们在此略过，因为我们已经足够熟悉 rayon 的 Consumer 概念。最后，求和：

    fn sum<S>(self) -> S
        where S: Send + Sum<Self::Item> + Sum<S>
    {
        sum::sum(self)
    }

这在 src/iter/sum.rs 中定义为：

pub fn sum<PI, S>(pi: PI) -> S
    where PI: ParallelIterator,
          S: Send + Sum<PI::Item> + Sum
{
    pi.drive_unindexed(SumConsumer::new())
}

生产者被驱动到 SumConsumer，它将求和工作分配到线程池中，然后最终将其折叠成一个单一值。

就这样 就是 了。这就是 rayon。它是一个可以自动在线程之间分配工作负载的线程池，以及一系列 Iterator 适配器，这些适配器大大减少了利用线程池模型所需的工作量。

现在你知道了！这不仅仅是 rayon 能做的——它是一个非常有用的库——但这才是核心思想。我强烈建议你阅读 rayon 的文档。

数据并行和操作系统进程 – Corewars 玩家的演变

在本章的最后一节，我想介绍一个项目，这个项目将带领我们进入下一章。这个项目将把本章中我们介绍的概念串联起来，并引入一个新的概念：进程。与线程相比，进程有很多值得推荐的地方：内存隔离、独立的优先级调度、方便地将现有程序集成到自己的系统中，以及处理它们的长久历史标准 syscalls（在 Unix 中）。但是，当你的目标是同时从多个并发操作者中玩弄相同的内存（如在原子编程中）或你不得不设置昂贵的 IPC 通道时，内存隔离就不太理想了。更糟糕的是，一些操作系统在创建新进程方面速度不快，限制了多进程程序在几个方面利用 CPU 的能力。尽管如此，了解如何创建和操作操作系统进程 确实 非常有用，我们在这本书中不讨论它将是失职的。

Corewars

Corewars 是 20 世纪 80 年代的一款计算机程序员游戏。在 1984 年的《科学美国人》文章中首次介绍，这款游戏是两个或更多程序——或战士——之间的竞争，这些程序是用一种名为 Redcode 的晦涩汇编语言编写的。实际上，Redcode 有两种有效变体，其中一种具有一些很好的特性，如标签或用于变量赋值的伪操作码。这通常被称为 Redcode。另一种变体被称为加载文件 Redcode或简单地称为加载文件，它是对操作码的直接读取。Redcode 针对的机器是内存数组 Redcode 模拟器（MARS）。它是……独特的。内存是有限且循环的，在回绕之前的最大地址是core_size-1。大多数玩家将core_size设置为 8000，但任何值都是有效的。每个内存位置都是一个指令。指令缓存和数据存储之间没有区别。实际上，并没有真正的数据存储，尽管你可以在指令的未使用部分存储信息。在 MARS 机器中不存在绝对内存寻址：每个地址都是相对于内存环中当前指令的相对地址。例如，以下指令将告诉 MARS 在内存中向后跳两个位置并从那里继续执行：

JMP -2

MARS 按顺序依次执行每个战士的一条指令，顺序与 MARS 将战士加载到内存中的顺序相同。战士们从某个偏移量开始，并保证它们之间不会重叠。战士可以产生子战士，这个子战士将像其他所有战士一样被执行。单个操作码DAT将导致战士退出。游戏的目标是迫使对方战士执行DAT。在模拟中最后存活的战士——以及任何产生的战士——赢得游戏。

Corewars 的细节远不止这里所展示的，包括操作码列表、内存模式等，但这不是 Corewars 教程。网上有很多优秀的教程，我在进一步阅读部分也推荐了一些。重要的是要理解，Corewars 是一种程序员之间的游戏，游戏双方通过编写程序进行竞争。MARS 有很多模拟器，但最常用的是*pMARS (www.koth.org/pmars/)，或便携式 MARS。即使在现代 GCC 下，它也能很容易地构建，尽管我无法保证在 clang 下能构建它。

这里是来自 pmars 0.9.2 源分布的一个相当有趣的轰炸机，让你对这些程序的外观有一个大致的了解：

;redcode-94
;name Rave
;author Stefan Strack
;strategy Carpet-bombing scanner based on Agony and Medusa's
;strategy (written in ICWS'94)
;strategy Submitted: @date@
;assert CORESIZE==8000

CDIST   equ 12
IVAL    equ 42
FIRST   equ scan+OFFSET+IVAL
OFFSET  equ (2*IVAL)
DJNOFF  equ -431
BOMBLEN equ CDIST+2

        org comp

scan    sub.f  incr,comp
comp    cmp.i  FIRST,FIRST-CDIST        ;larger number is A
        slt.a  #incr-comp+BOMBLEN,comp  ;compare to A-number
        djn.f  scan,<FIRST+DJNOFF       ;decrement A- and B-number
        mov.ab #BOMBLEN,count
split   mov.i  bomb,>comp               ;post-increment
count   djn.b  split,#0
        sub.ab #BOMBLEN,comp
        jmn.b  scan,scan
bomb    spl.a  0,0
        mov.i  incr,<count
incr    dat.f  <0-IVAL,<0-IVAL
        end

一枚轰炸机以偏移间隔将炸弹扔入内存。一些扔DAT，如果执行，将迫使战士退出。这一枚扔了一个 imp。imp 是 Corewars 程序，每次在内存中前进一定数量的指令。在 1984 年的文章中引入的 Imp 是：

MOV.I 0 1

这里的操作码是带有修改符I的MOV，源地址为 0，目标地址为 1。MOV将源地址（也传统上称为a 字段）的指令移动到目标地址（也称为b 字段）。操作码修改符——.I——定义了操作码如何解释其命令。在这里，我们指定 MOV 将整个指令从当前单元格移动到环上的下一个单元格。MOV.A只会将当前指令的 a 字段移动到目标指令的 a 字段。轰炸机的小精灵mov.i incr,<count依赖于先前计算出的值，在内存中放置小精灵，它们以不同的速率和不同的偏移量前进。b 字段上的<是一个带有预减量操作符的间接地址，但正如我所说的，这不是一个 Corewars 教程。

pMARS 模拟器可以读取加载文件和 Redcode，将战士放入模拟器中，并报告结果。在这里，我们运行了 100 次模拟回合的轰炸机对抗小精灵：

> pmars -b -r 1000 imp.red rave.red
Imp by Alexander Dewdney scores 537
Rave by Stefan Strack scores 1926
Results: 0 463 537

这个小精灵的表现并不太好。它赢了 0 次，但成功打平了 537 次。小精灵很难被杀死。

编写战士很有趣，但教计算机编写战士更有趣，所以这就是我们要着手去做的事情。具体来说，我们将编写一个进化器，这是一个使用战士种群的模拟进化来产生越来越适应环境的样本的程序。我们将调用 pMARS 可执行文件来评估我们的种群，并且，如果有足够的时间，希望出现一些相当令人印象深刻的东西。

Feruscore – 一个 Corewars 进化器

在我们开始挖掘源代码之前，我想确保我们都在同一页面上。模拟进化的工作方式是，你创建一个种群——可能是完全随机的，也可能不是——并将其称为第 0 代。然后你对种群成员运行一些fitness函数。适应性可以定义为某些已知的绝对值，或者种群成员之间的相对值。种群中最适应的成员随后被选为父母的一个子集。许多算法采用两个成员，但天空才是极限，你的物种可能需要六个个体进行繁殖。这正是我们追求的——繁殖。

种群中的个体以非破坏性的方式重新组合形成孩子。然后种群发生变异，以某些领域特定的概率改变个体的基因组中的基因。这可能涉及种群中的所有成员，或者只是孩子，或者只是父母，或者你想要的任何组合。这里没有完美的答案。变异后，父母、他们的孩子以及任何在适应性评估期间没有死亡的种群的非繁殖成员将被提升到第 2 代。这个循环继续进行：

• 适应性评估

• 父母繁殖

• 种群发生变异

周期何时停止取决于程序员：可能是经过固定数量的代数后，也可能是当某个个体进化出满足某些最小适应性阈值时。

模拟进化不是魔法。就像 QuickCheck，它使用随机性来探测程序的属性违规，这个算法正在探测问题空间中最适合的解决方案。它是一种优化策略，模仿生物过程。正如你可能从刚才给出的描述中推断出的，基本方法有很多可调节的旋钮和替代方案。我们在这里将采用一种简单的方法，但强烈鼓励你根据自己的需要进行修改。

表示领域

在我们开始进化任何东西之前，我们必须弄清楚如何表示个体；我们需要决定如何构建他们的染色体。许多遗传算法实现将这些表示为 [u8]，根据需要序列化和反序列化。这种表示有很多优点。首先，现代计算机有专门针对并行操作多个字节的指令——这是一个我们将在第十章 未来主义 – 近期 Rust 中涉及的话题——这对于遗传算法的突变和繁殖阶段特别有帮助。你看，成功模拟进化的关键之一是 速度。我们需要一个大型种群和许多许多代来发现适合的个体。[u8] 是序列化和反序列化的便利表示，特别是当有 serde (https://crates.io/crates/serde) 和 bincode (crates.io/crates/bincode) 这样的工具时。[u8] 表示的缺点是创建无法反序列化为有效内容的个体，以及在 [u8] 和结构体之间移动时消耗 CPU 时间。

程序优化归结为精心构建计算结构以适应计算机或找到避免计算的整体巧妙方法。在这个特定项目中，我们确实有一个可以玩的技巧。一个有效的个体是一个有限的指令列表——feruscore 目标生成 加载文件——然后我们只需要将一个指令表示为一个 Rust 结构体并将其放入一个向量中。不错！这将为我们节省大量的 CPU 时间，尽管我们的突变步骤会稍微慢一些。不过没关系，因为正如我们很快就会看到的那样，适应性评估将是最大的时间消耗。

探索源代码

让我们先看看 feruscore 的 Cargo.toml。它是：

[package]
name = "feruscore"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
rand = "0.4"
rayon = "1.0"
tempdir = "0.3"

我们在第五章中看到了 tempdir crate，锁 - Mutex, Condvar, Barriers 和 RWLock；它的目的是创建在目录处理程序被丢弃时删除的临时目录。我们在本章前面讨论了 rayon。rand crate 是新的，尽管我们在第二章 顺序 Rust 性能和测试和第五章 锁 - Mutex, Condvar, Barriers 和 RWLock中提到了它，当时我们产生了自己的 XorShift。rand crate 实现了许多不同的伪随机算法，同时提供了一个方便的接口来访问 OS 的随机性设施。我们将充分利用 rand。

该项目是一个标准库/可执行文件包。与本书中的许多其他项目不同，我们不是创建多个可执行文件，因此只有一个src/main.rs。我们将在适当的时候讨论这一点。库根目录在src/lib.rs：

extern crate rand;
extern crate rayon;
extern crate tempdir;

pub mod individual;
pub mod instruction;

指令

没有惊喜。我们导入项目依赖项并公开两个公共模块：instruction 和 individual。src/instruction.rs中的 instruction 模块是 feruscore 版本的[u8]，或者更确切地说，是数组中的u8。让我们看看。根目录的结构是Instruction：

#[derive(PartialEq, Eq, Copy, Clone, Debug)]
pub struct Instruction {
    pub opcode: OpCode,
    pub modifier: Modifier,
    pub a_mode: Mode,
    pub a_offset: Offset,
    pub b_mode: Mode,
    pub b_offset: Offset,
}

Redcode 中的指令是一个操作码，该操作码的修饰符，一个 a 偏移量加修饰符和一个 b 偏移量加修饰符。（a 字段和 b 字段是偏移量和模式的组合。）这正是我们在这里所拥有的。不需要从字节数组反序列化；我们将直接处理表示。Instruction的实现很小。首先，我们需要一种创建随机Instruction的方法：

impl Instruction {
    pub fn random(core_size: u16) -> Instruction {
        Instruction {
            opcode: OpCode::random(),
            modifier: Modifier::random(),
            a_mode: Mode::random(),
            a_offset: Offset::random(core_size / 32),
            b_mode: Mode::random(),
            b_offset: Offset::random(core_size / 32),
        }
    }

这将设置我们将在整个模块中使用的模式。每个类型都公开了random() -> Self或其变体。注意，偏移量限制为传递的core_size的 1/32。为什么？因为我们正在尝试减少正在探索的域的基数。假设核心大小为 8,000。如果在偏移量中尝试了所有可能的核心大小值实例，将会有 6400 万个可能的Instruction，不包括与其他结构体字段的有效组合。根据我对高分战士的了解，显式偏移量通常是较小的数字。

通过减少偏移量域，我们消除了 6200 万个潜在的指令，节省了 CPU 时间。这很可能是悲观限制——迫使种群直接进入瓶颈——但我怀疑不是。这个模块中的每个结构体也都有一个serialize(&self, w: &mut Write) -> io::Result<usize>函数。以下是Instruction的示例：

    pub fn serialize(&self, w: &mut Write) -> io::Result<usize> {
        let mut total_written = 0;
        self.opcode.serialize(w)?;
        total_written += w.write(b".")?;
        self.modifier.serialize(w)?;
        total_written += w.write(b" ")?;
        total_written += match self.a_mode {
            Mode::Immediate => w.write(b"#")?,
            Mode::Direct => w.write(b"$")?,
            Mode::Indirect => w.write(b"*")?,
            Mode::Decrement => w.write(b"{")?,
            Mode::Increment => w.write(b"}")?,
        };
        self.a_offset.serialize(w)?;
        total_written += w.write(b", ")?;
        total_written += match self.b_mode {
            Mode::Immediate => w.write(b"#")?,
            Mode::Direct => w.write(b"$")?,
            Mode::Indirect => w.write(b"@")?,
            Mode::Decrement => w.write(b"<")?,
            Mode::Increment => w.write(b">")?,
        };
        total_written += self.b_offset.serialize(w)?;
        total_written += w.write(b"\n")?;
        Ok(total_written)
    }
}

当我们运行 feruscore 时，我们将调用本地系统的 pmars 可执行文件，该程序需要在磁盘上查找文件。每次我们检查适应性时，每个个体的每个Instruction都将被序列化到磁盘上。那个加载文件将由 pmars 反序列化，在模拟中运行，并将结果通过 pmars 的 stdout 返回给 feruscore。这不是一个快速的过程。

指令模块的其余部分遵循这个一般框架。例如，这里有一个Modifier结构体：

#[derive(PartialEq, Eq, Copy, Clone, Debug)]
pub enum Modifier {
    A,
    B,
    AB,
    BA,
    F,
    X,
    I,
}

这里是实现的代码：

impl Modifier {
    pub fn random() -> Modifier {
        match thread_rng().gen_range(0, 7) {
            0 => Modifier::A,
            1 => Modifier::B,
            2 => Modifier::AB,
            3 => Modifier::BA,
            4 => Modifier::F,
            5 => Modifier::X,
            6 => Modifier::I,
            _ => unreachable!(),
        }
    }

    pub fn serialize(&self, w: &mut Write) -> io::Result<usize> {
        match *self {
            Modifier::A => w.write(b"A"),
            Modifier::B => w.write(b"B"),
            Modifier::AB => w.write(b"AB"),
            Modifier::BA => w.write(b"BA"),
            Modifier::F => w.write(b"F"),
            Modifier::X => w.write(b"X"),
            Modifier::I => w.write(b"I"),
        }
    }
}

个人

没有什么特别的，尤其是在本书的这个阶段。random() -> Self函数有点脆弱，因为你不能查询枚举的总字段数，这意味着如果我们从Modifier中添加或删除字段，例如，我们也必须记得适当地更新gen_range(0, 7)。删除并不那么糟糕，编译器会抱怨一些，但添加很容易忘记和忽略。

现在我们来看一下个人模块。大部分代码都在 src/individual/mod.rs 中。个人的结构体非常简短：

#[derive(Debug)]
pub struct Individual {
    chromosome: Vec<Option<Instruction>>,
}

一个Individual是一个染色体，除此之外没有别的，就像我们讨论的那样，一个指令的向量。Individual上的函数提供了根据进化算法讨论的预期功能。首先，我们必须能够创建一个新的Individual：

impl Individual {
    pub fn new(chromosome_size: u16, core_size: u16) -> Individual {
        let mut chromosome = Vec::with_capacity(chromosome_size as usize);
        chromosome.par_extend((0..(chromosome_size as usize))
                  .into_par_iter().map(|_| {
            if thread_rng().gen_weighted_bool(OpCode::total() * 2) {
                None
            } else {
                Some(Instruction::random(core_size))
            }
        }));
        Individual { chromosome }
    }

啊！现在我们遇到了一些新东西。par_extend是什么？这是一个 rayon 函数，简称并行扩展。让我们从内到外工作。内部映射忽略其参数，并以 1/28 的概率产生一个None——OpCode变体的总数是 14——以及 27/28 的概率产生其他随机的Instruction：

map(|_| {
    if thread_rng().gen_weighted_bool(OpCode::total() * 2) {
        None
    } else {
        Some(Instruction::random(core_size))
    }
})

内部映射如此仔细忽略的输入是(0..(chromosome_size as usize)).into_par_iter()。这是一个覆盖从 0 到个体允许的最大染色体数的范围的ParallelIterator。Corewars 早期的一个创造性解决方案是提交一个MOV 0 1指令，后面跟着 7999 个DAT指令。如果 MARS 加载了你的战士并且没有编程来仔细检查战士偏移量，你的对手会因为立即被覆盖而输掉。很快，就实施了指令长度限制，我们在这里也遵守这个规则。Individual的序列化遵循我们熟悉的模式：

    pub fn serialize(&self, w: &mut Write) -> io::Result<usize> {
        let mut total_wrote = 0;
        for inst in &self.chromosome {
            if let Some(inst) = inst {
                total_wrote += inst.serialize(w)?;
            } else {
                break;
            }
        }
        Ok(total_wrote)
    }

变异和繁殖

在我们讨论两个Individual之间的竞争之前，让我们先谈谈变异和繁殖。在我看来，变异比繁殖更容易理解，因为它一次只操作一个Individual。我们的实现：

    pub fn mutate(&mut self, mutation_chance: u32, core_size: u16) -> () {
        self.chromosome.par_iter_mut().for_each(|gene| {
            if thread_rng().gen_weighted_bool(mutation_chance) {
                *gene = if thread_rng().gen::<bool>() {
                    Some(Instruction::random(core_size))
                } else {
                    None
                };
            }
        });
    }

par_iter_mut的调用创建了一个ParallelIterator，其中迭代器的元素是可变的，就像标准库中的iter_mut一样。for_each操作符将闭包应用于每个元素。for_each操作符在目的上与map类似，但它将不可避免地消耗输入，但可以避免分配新的底层集合。就地修改一个东西？使用for_each。从现有的存储中创建一个新东西？使用map。无论如何，feruscore 使用的变异策略足够简单。染色体中的每个Instruction都有1/mutation_chance的概率被改变，并且有 1/2 的概率被禁用，即设置为None。仔细的读者会注意到，序列化器在染色体中找到None时停止序列化指令，使得之后的 DNA 都变成了垃圾 DNA。这些垃圾 DNA 在繁殖过程中仍然会发挥作用：

    pub fn reproduce(&self, partner: &Individual, 
                     child: &mut Individual) -> () 
    {
        for (idx, (lgene, rgene)) in self.chromosome
            .iter()
            .zip(partner.chromosome.iter())
            .enumerate()
        {
            child.chromosome[idx] = if thread_rng().gen::<bool>() {
                *lgene
            } else {
                *rgene
            };
        }
    }

Feruscore 使用一种称为半均匀交叉的繁殖策略。每个来自父母的基因有平等的机会进入子代。子代以可变引用的形式传递，如果你仔细思考，这会让人感到有些诡异。我不确定有任何真正的物种会接管一个不太适合个体的身体，并将 DNA 热插拔进去，以形成一个孩子来节省能量（或者在我们的情况下，节省计算）。但在这里我们就是这样做的。注意，与变异不同，繁殖是串行进行的。记住，rayon 正在分块工作并通过线程池分配。如果我们想并行化这个过程，就需要有一个机制来纠正从父母染色体的接合处到子代的基因选择。如果染色体有多个兆字节，这将是一个很好的可以尝试的地方。目前，染色体非常小。大多数 Corewars 游戏将战士的限制设置为 100 条指令。rayon 很令人印象深刻，但它也不是免费的，无论是运行时成本还是编程工作量。

竞争——调用 pMARS

现在是考虑每个Individual如何竞争的时候了。之前，我们讨论了在系统上调用 pmars，这需要两个竞争的个体战士的磁盘表示。正如预期的那样，竞争首先将两个战士序列化到磁盘上的临时位置：

    pub fn compete(&self, other: &Individual) -> Winner {
        let dir = TempDir::new("simulate")
                      .expect("could not make tempdir");

        let l_path = dir.path().join("left.red");
        let mut lfp = BufWriter::new(File::create(&l_path)
                          .expect("could not write lfp"));
        self.serialize(&mut lfp).expect("could not serialize");
        drop(lfp);

        let r_path = dir.path().join("right.red");
        let mut rfp = BufWriter::new(File::create(&r_path)
                          .expect("could not write rfp"));
        other.serialize(&mut rfp).expect("could not serialize");
        drop(rfp);

在这本书中，我们与文件系统的交互并不多，但可以这么说，Rust 在标准库中有一个出色的文件系统设置，大部分都在std::fs下。如果你对这些函数不熟悉，强烈建议你查看它们的文档。无论如何，当两个战士都写入磁盘后，我们可以在它们上运行 pmars：

        let output = Command::new("pmars")
            .arg("-r") // Rounds to play
            .arg(format!("{}", ROUNDS))
            .arg("-b") // Brief mode (no source listings)
            .arg(&l_path)
            .arg(&r_path)
            .output()
            .expect("failed to execute process");

让我们来分析一下这里发生的事情。std::process::Command是一个用于运行操作系统进程的构建结构体。如果我们只是对新的Command调用Command::output(&mut self)而不做其他操作，那么：

• pmars 将不带参数运行

• feruscore 的工作目录和环境将变为 pmars

• pmars 的 stdout 将被管道回 feruscore 进程

这些都可以更改。pmars 的实际执行不会发生，直到调用输出：或者，spawn，它旨在用于长期运行的过程。Command::stdin、Command::stderr 和 Command::stdout 函数控制进程的 IO 行为，feruscore 的描述符是否被子进程继承——这是 spawn 的情况——或者管道回 feruscore，这是输出的默认设置。我们不希望 pmars 写入 feruscore 的 stdout/sterr，所以 output 的默认值非常适合我们的需求。对 args 的调用向 Command 添加了一个新参数，即使对于关联参数也需要新的调用。我们写 .arg("-r").arg(format("{}", ROUNDS)) 而不是 .arg(format!("-r {}", ROUNDS))。在这里，如果 pmars 无法生成适当的输出，程序会崩溃，这可能发生在可执行文件找不到或我们触发了 pmars 的崩溃错误，并且我们没有权限运行程序。崩溃对用户来说有点不友好，但对我们这里的用途来说足够好了。

现在，output: std::process::Output，一个有三个成员的结构体。我们忽略了退出状态，而是提取了最后一行 stdio：

        let result_line = ::std::str::from_utf8(&output.stdout)
            .expect("could not parse output")
            .lines()
            .last()
            .expect("no output");

如果在 stdio 上有输出，那么 pmars 成功运行了传入的战士，如果没有，那么战士是无效的。pmars 中的解析器在战士未能加载 Individual 或 Instruction 的序列化器时非常宽容。注意，result_line 是输出的最后一行。最后一行总是以下形式：Results: 10 55 32，这意味着左边的程序赢了 10 次，右边的程序赢了 55 次，它们平局了 32 次。平局发生在没有一个战士能够通过预定的执行次数迫使另一个战士退出游戏，通常在 10,000 次左右。解析最后一行是一项艰巨的工作：

        let pieces = result_line.split(' ').collect::<Vec<&str>>();

        let l_wins = pieces[1].parse::<u16>()
                         .expect("could not parse l_wins");
        let r_wins = pieces[2].parse::<u16>()
                         .expect("could not parse r_wins");
        let ties = pieces[3].parse::<u16>()
                         .expect("could not parse ties");
        assert_eq!((l_wins + r_wins + ties) as usize, ROUNDS);

注意这个断言。ROUNDS 是模块中设置的一个常量，设置为 100。我们的 Command 告知 pmars 与传入的战士进行 100 轮比赛，如果结果不等于 100，我们就有真正的问题了。在代码中放置这些合理性检查有时感觉有点愚蠢，但，令人惊讶的是，它们确实能找出错误。同样，投资于诊断很少是徒劳的。例如，在遗传算法中，很难知道你的种群中情况如何。每一代都在变得更健康吗？种群是否在某处出现了瓶颈？为此，竞争的下一步是统计左右战士的适应性：

        tally_fitness(l_wins as usize);
        tally_fitness(r_wins as usize);

tally_fitness 函数的定义如下：

fn tally_fitness(score: usize) -> () {
    assert!(score <= ROUNDS);

    match score {
        0...10 => FITNESS_00010.fetch_add(1, Ordering::Relaxed),
        11...20 => FITNESS_11020.fetch_add(1, Ordering::Relaxed),
        21...30 => FITNESS_21030.fetch_add(1, Ordering::Relaxed),
        31...40 => FITNESS_31040.fetch_add(1, Ordering::Relaxed),
        41...50 => FITNESS_41050.fetch_add(1, Ordering::Relaxed),
        51...60 => FITNESS_51060.fetch_add(1, Ordering::Relaxed),
        61...70 => FITNESS_61070.fetch_add(1, Ordering::Relaxed),
        71...80 => FITNESS_71080.fetch_add(1, Ordering::Relaxed),
        81...90 => FITNESS_81090.fetch_add(1, Ordering::Relaxed),
        91...100 => FITNESS_91100.fetch_add(1, Ordering::Relaxed),
        _ => unreachable!(),
    };
}

你可能会问这是什么呢？好吧，我会告诉你！tally_fitness 接收输入分数——战士的胜利数——并将这个分数放入一个直方图中。通常这是通过取模运算来完成的，但我们在这里遇到了困难。实现必须假设 tally_fitness 将由多个线程同时运行。因此，我们使用几个具有暗示其桶用途的名称的离散 AtomicUsizes 构建了一个直方图。静态声明的重复性正如你所想象的那样，我们在这里就不重复了。手动维护这种结构确实很痛苦，但它确实为你提供了一个原子直方图，只要你对那个直方图也是静态的没有问题。这个实现就是这样。直方图不是用于决策，而是用于诊断显示。当我们讨论主循环时，我们会回到这一点。

compete 的最后几行令人失望：

        if l_wins > r_wins {
            Winner::Left(l_wins)
        } else if l_wins < r_wins {
            Winner::Right(r_wins)
        } else {
            Winner::Tie
        }
    }
}

每个战士的胜利次数被比较，获胜者被宣布为得分更高的那个，或者两者都没有获胜，宣布为平局。根据你的问题域，这个适应度的标准可能太粗糙了。从输出中，我们不知道个体相对于其竞争对手有多适应，只知道它是。战士们可能在 0 胜利的情况下打平，或者 50/50。我们相信这个简单的信号足够了，至少对我们现在的目的来说是这样。

至少就创建一个 Individual、修改它、繁殖它和竞争它而言，这就足够了！现在剩下的只是模拟进化，而为了做到这一点，我们必须跳转到 main.rs。在我们这样做之前，我想简要指出，这里有一个子模块，individuals::ringers。这个模块有如下函数：

pub fn imp(chromosome_sz: u16) -> Individual {
    let mut chromosome = vec![
        // MOV.I $0, $1
        Some(Instruction {
            opcode: OpCode::Mov,
            modifier: Modifier::I,
            a_mode: Mode::Direct,
            a_offset: Offset { offset: 0 },
            b_mode: Mode::Direct,
            b_offset: Offset { offset: 1 },
        }),
    ];
    for _ in 0..(chromosome_sz - chromosome.len() as u16) {
        chromosome.push(None);
    }
    Individual { chromosome }
}

有时候，通过在随机的混合物中撒一点启动剂来推动进化是有智慧的。Feruscore 没有解析器——至少，直到某个读者贡献一个——所以战士们被写成长格式。

现在，让我们继续 main！

主程序

src/main.rs 的前言与我们在本书中看到的程序典型：

extern crate feruscore;
extern crate rand;
extern crate rayon;

use feruscore::individual::*;
use rand::{thread_rng, Rng};
use rayon::prelude::*;
use std::collections::VecDeque;
use std::fs::File;
use std::fs::{self, DirBuilder};
use std::io::{self, BufWriter};
use std::path::{Path, PathBuf};
use std::sync::atomic::{AtomicUsize, Ordering};
use std::{thread, time};

程序确实开始了，但是，它开始于一个异常大的常量和静态块：

// configuration
const POPULATION_SIZE: u16 = 256; // NOTE must be powers of two
const CHROMOSOME_SIZE: u16 = 25; // Must be <= 100
const PARENTS: u16 = POPULATION_SIZE / 8;
const CHILDREN: u16 = PARENTS * 2;
const RANDOS: u16 = POPULATION_SIZE - (PARENTS + CHILDREN);
const CORE_SIZE: u16 = 8000;
const GENE_MUTATION_CHANCE: u32 = 100;

// reporting
static GENERATIONS: AtomicUsize = AtomicUsize::new(0);
static REGIONAL_BATTLES: AtomicUsize = AtomicUsize::new(0);
static FINALS_BATTLES: AtomicUsize = AtomicUsize::new(0);
static STATE: AtomicUsize = AtomicUsize::new(0);
static NEW_PARENTS: AtomicUsize = AtomicUsize::new(0);

实际上，配置常数可以通过敲击或某些配置解析库调整成实际配置。与 serde 配对的 toml (crates.io/crates/toml) crate 对于解析简单的配置非常有用，其中验证步骤只是我们现在编码为注释的几个检查。报告统计量与我们在书中看到的相同的静态 AtomicUsizes。实际上，启动报告线程是 main 函数做的第一件事：

fn main() {
    let _ = thread::spawn(report);

report 线程的工作方式与书中其他地方扮演类似角色的线程相似：全局静态变量——包括来自 feruscore::individuals 的 FITNESS_*——被交换为零，进行一点计算，然后有一个打印到标准输出的块，最后线程休眠一段时间，然后再次循环，永远如此。到这时，这已经是一个老套的技术了。

当报告线程在线时，feruscore 创建其初始人口：

    let mut population: Vec<Individual> = 
        Vec::with_capacity(POPULATION_SIZE as usize);
    let mut children: Vec<Individual> = 
        Vec::with_capacity(CHILDREN as usize);
    let mut parents: VecDeque<Individual> = 
        VecDeque::with_capacity(PARENTS as usize);
    population.par_extend(
        (0..POPULATION_SIZE)
            .into_par_iter()
            .map(|_| Individual::new(CHROMOSOME_SIZE, CORE_SIZE)),
    );
    population.pop();
    population.pop();
    population.push(ringers::imp(CHROMOSOME_SIZE));
    population.push(ringers::dwarf(CHROMOSOME_SIZE));

rayon 的 par_extend 再次出现，当 POPULATION_SIZE 是一个很大的数字时很有用，但以其当前值来说并不有害。正如我们所见，rayon 会拒绝分割一个太小以至于无法有效并行化的并行集合，分配给线程的时间超过了计算时间。Individual::new 被实际染色体和核心大小调用，并且两个不幸的、随机的种群成员被驱逐并释放，以换取来自 individual::ringers 的替代者。

有许多方法可以决定人口中个体的适应性。feruscore 采取的方法是在锦标赛中运行个体。第一场锦标赛的胜者成为第一个父代，第二场锦标赛的胜者成为第二个父代，以此类推，直到每个父代都填满。这种实现简短但包含了许多内容：

    loop {
        // tournament, fitness and selection of parents
        STATE.store(0, Ordering::Release);
        while parents.len() < PARENTS as usize {
            thread_rng().shuffle(&mut population);
            let res = population
                .into_par_iter()
                .fold(|| (None, Vec::new()), regional_tournament)
                .reduce(|| (None, Vec::new()), finals_tournament);
            population = res.1;
            parents.push_back(res.0.unwrap());
            NEW_PARENTS.fetch_add(1, Ordering::Relaxed);
        }

这里发生了什么？人口在开始时被随机排列，以避免在每一场锦标赛中配对相同的个体。线程的不确定性使得这一点有些不必要的，而且对速度痴迷的进化者可能最好去掉这一点。主要展示的是人口的结构化和简化。熟悉函数式编程的读者可能会惊讶地发现，rayon 的 fold 和 reduce 并非同义词。ParallelIterator::fold 的类型如下：

fold<T, ID, F>(self, identity: ID, fold_op: F) 
    -> Fold<Self, ID, F> 
where
    F: Fn(T, Self::Item) -> T + Sync + Send,
    ID: Fn() -> T + Sync + Send,
    T: Send,

熟悉函数式编程的读者不会对 fold 的类型有些复杂感到惊讶。开个玩笑，请注意，该函数不返回 T 的实例，而是返回 Fold<Self, ID, F>，其中 Fold: ParallelIterator。rayon 的 fold 不产生单个 T，而是产生一个并行迭代器，遍历块，并将 Fn(T, Self::Item) -> T 应用到这些块上：折叠块的迭代器。ParallelIterator::reduce 有以下类型：

reduce<OP, ID>(self, identity: ID, op: OP) 
    -> Self::Item 
where
    OP: Fn(Self::Item, Self::Item) -> Self::Item + Sync + Send,
    ID: Fn() -> Self::Item + Sync + Send,

OP 接受两个 Item 并将它们组合成一个 Item。然后，Reduce 接受 Item 的 ParallelIterator 并将它们简化为单个 Item 类型的实例。我们的锦标赛实现将 regional_tournament 折叠到人口上，产生一个 (Option<Individual>, Vec<Individual>) 的 Fold，元组的第一个元素是那个种群子块中最适应的个体，第二个元素是种群的其他部分。然后，reduce 步骤将区域锦标赛的胜者简化为最终的胜者。这两个函数的实现相似。首先，regional_tournament：

fn regional_tournament(
    (chmp, mut population): (Option<Individual>, Vec<Individual>),
    indv: Individual,
) -> (Option<Individual>, Vec<Individual>) {
    if let Some(chmp) = chmp {
        REGIONAL_BATTLES.fetch_add(1, Ordering::Relaxed);
        match chmp.compete(&indv) {
            Winner::Left(_) | Winner::Tie => {
                population.push(indv);
                (Some(chmp), population)
            }
            Winner::Right(_) => {
                population.push(chmp);
                (Some(indv), population)
            }
        }
    } else {
        (Some(indv), population)
    }
}

注意到在出现平局时，需要调用竞争并选择将现有的chmp——冠军——提升到下一轮锦标赛的选项。REGIONAL_BATTLES进行了更新，向报告线程提供信息。适应性较差的个体被推回种群中。finals_tournament稍微复杂一些，但遵循相同的路线：

fn finals_tournament(
    (left, mut lpop): (Option<Individual>, Vec<Individual>),
    (right, rpop): (Option<Individual>, Vec<Individual>),
) -> (Option<Individual>, Vec<Individual>) {
    if let Some(left) = left {
        lpop.extend(rpop);
        if let Some(right) = right {
            FINALS_BATTLES.fetch_add(1, Ordering::Relaxed);
            match left.compete(&right) {
                Winner::Left(_) | Winner::Tie => {
                    lpop.push(right);
                    (Some(left), lpop)
                }
                Winner::Right(_) => {
                    lpop.push(left);
                    (Some(right), lpop)
                }
            }
        } else {
            (Some(left), lpop)
        }
    } else {
        assert!(lpop.is_empty());
        (right, rpop)
    }
}

此函数负责重新运行比赛并连接种群中先前分裂的部分。注意对lpop.extend的调用。正确的种群——rpop——总是合并到左侧种群中，适应性较差的个体也是如此。没有特殊的原因，我们同样可以合并右侧并返回右侧。

现在，花一分钟看看这两个函数。它们是顺序的。我们能够像顺序函数一样推理它们，能够像顺序函数一样编程它们，能够像顺序函数一样测试它们。rayon 的内部模型不会泄露到这段代码中。我们只需要理解类型，一旦完成，rayon 就能做它的事情。这种内部顺序、外部并行的模型是独特的，与我们迄今为止在书中讨论的所有技术相比。rayon 的实现无疑很复杂，但一旦掌握了迭代器风格，它所允许的编程模型就相当简单。

一旦锦标赛选择完成，父母向量被填充为PARENTS，Individuals 的数量，种群中有成员都适合成为孩子。为什么从种群中抽取？好吧，好处是我们避免了每次繁殖都要重新分配一个新的Individual。许多小的分配很快就会变得昂贵。缺点是，通过从种群中抽取，我们无法轻松地将直接循环转换为并行迭代器。鉴于繁殖的总数很小，实现并没有尝试任何并行化，而只是进行了一个串行循环：

        STATE.store(1, Ordering::Release);
        while children.len() < CHILDREN as usize {
            let parent0 = parents.pop_front().expect("no parent0");
            let parent1 = parents.pop_front().expect("no parent1");
            let mut child = population.pop().expect("no child");
            parent0.reproduce(&parent1, &mut child);
            children.push(child);
            parents.push_back(parent0);
            parents.push_back(parent1);
        }

移除两个父母和一个孩子，发生繁殖，每个人都进入各自的集合。孩子存在是为了避免多次繁殖相同的Individual。繁殖完成后，children会合并回种群，但在合并之前会进行一些合理性检查：

        assert_eq!(children.len(), CHILDREN as usize);
        assert_eq!(parents.len(), PARENTS as usize);
        assert_eq!(population.len(), RANDOS as usize);

        population.append(&mut children);

一旦children被整合到种群中，就会发生变异：

        STATE.store(2, Ordering::Release);
        population.par_iter_mut().for_each(|indv| {
            let _ = indv.mutate(GENE_MUTATION_CHANCE, CORE_SIZE);
        });

仔细的读者会注意到父母不包括在变异步骤中。这是故意的。一些实现会在给定的一代中对父母进行变异，而是否这样做取决于领域。在这里，适应良好的Individual和适应性较差的Individual之间的差异很小，我认为最好让父母保持原样。这是一个需要实验的问题。

最后，我们增加generation，可能还有checkpoint，并将父母重新整合到种群中：

        let generation = GENERATIONS.fetch_add(1, Ordering::Relaxed);
        if generation % 100 == 0 {
            checkpoint(generation, &parents)
                .expect("could not checkpoint");
        }

        for parent in parents.drain(..) {
            population.push(parent);
        }
    }
}

feruscore 中没有停止条件。相反，每 100 代，程序将将其最佳战士——父母——写入磁盘。用户可以按需使用这些信息。在固定代数后停止模拟或比较父母与众多已知最佳战士，当进化出一个能够击败他们的战士时退出，这是合理的。最后这一点特别酷，但需要解析器或相当多的手动组装。检查点看起来可能像这样：

fn checkpoint(generation: usize, best: &VecDeque<Individual>) -> io::Result<()> {
    let root: PathBuf = Path::new("/tmp/feruscore/checkpoints")
                            .join(generation.to_string());
    DirBuilder::new().recursive(true).create(&root)?;
    assert!(fs::metadata(&root).unwrap().is_dir());

    for (idx, indv) in best.iter().enumerate() {
        let path = root.join(format!("{:04}.red", idx));
        let mut fp = BufWriter::new(File::create(&path)
                         .expect("could not write lfp"));
        indv.serialize(&mut fp)?;
    }

    Ok(())
}

好吧！让我们进化一些战士。

运行 feruscore

在尝试运行 feruscore 之前，请确保 pmars 已存在于您的 PATH 中。一些操作系统将 pmars 捆绑在其软件包发行中，而其他操作系统，如 OS X，则需要 gcc 来编译程序。pMARS 项目是值得尊敬的 C 代码，编译它可能有点麻烦。在我的 Debian 系统上，我不得不稍微调整一下 makefile，但在 OS X 上，我发现一个有用的 brew cask 来安装 pMARS。

一旦安装了 pMARS，您应该能够在项目的根目录下运行cargo run --release并收到以下类似输出：

GENERATION(0):
    STATE:          Tournament
    RUNTIME (sec):  4
    GENS/s:         0
    PARENTS:        2
       PARENTS/s:   1
    BATTLES:        660
       R_BATTLES/s: 131
       F_BATTLES/s: 25
    FITNESS:
        00...10:    625
        11...20:    1
        21...30:    3
        31...40:    0
        41...50:    130
        51...60:    3
        61...60:    0
        71...70:    0
        81...80:    0
        91...100:   550

哇！看看它运行的样子。这个 feruscore 实例已经运行了 4 秒——运行时间（秒）：4——并且到目前为止已经计算了两个父母。这一代已经经历了 660 场战斗：131 场区域和 25 场决赛。适应度直方图显示，人口相当均匀地糟糕，否则我们预计会在 0 端和 100 端看到一团。你应该会看到类似的东西。我敢打赌，你也会发现你的 CPU 被占满了。但是，有一个问题。这很慢。而且越来越糟。一旦我进化出更健康的战士，代数计算所需的时间就越长：

GENERATION(45):
    STATE:          Tournament
    RUNTIME (sec):  25297
    GENS/s:         0
    PARENTS:        8
       PARENTS/s:   0
    BATTLES:        1960
       R_BATTLES/s: 12
       F_BATTLES/s: 1
    FITNESS:
        00...10:    3796
        11...20:    0
        21...30:    0
        31...40:    0
        41...50:    0
        51...60:    0
        61...60:    0
        71...70:    0
        81...80:    0
        91...100:   118

虽然如此，但这是有道理的。人口越好，成员在回合中坚持的时间就越长。在找到真正优秀的解决方案之前，运行遗传算法数千代是很常见的事情。在当前实现中，一代至少需要慷慨地 30 秒。当我们能够进化出一个半不错的战士时，将是'94 ICWS Corewars 标准的 30 周年！这可不是什么好事。

结果表明，将Individual序列化到磁盘、启动 pMARS 进程并强制它解析序列化格式（加载文件）并不是一个快速的操作。我们还可以显著压缩Individual表示，提高模拟的缓存局部性。还有关于执行区域和决赛锦标赛以适应 rayon 所需的迭代器风格的问题。我们可以修复所有这些问题，但这些都得等到下一章。我们将把用 C 编写的 MARS 嵌入到 feruscore 中，由此将产生各种变化。

应该很有趣！

摘要

在本章中，我们将 Rust 中并发的基础细节作为基础。我们讨论了线程池，实际上，我们从前几章中就拥有了理解一个相当复杂的线程池的所有部件。然后我们探讨了 rayon，发现我们还可以理解一个隐藏在类型系统背后、用于在编程模型中实现数据并行的极其复杂的线程池。我们讨论了线程-连接模型的结构问题以及将小型数据集分割成数据并行迭代器的挑战。最后，我们进行了一个基于 rayon 和多进程的遗传算法项目的演练。与一些操作系统暴露的接口相比，std::process接口较为简洁，但经过深思熟虑且相当有用，正如在结束本章的 feruscore 项目中所示。我们将在下一章中继续探讨 feruscore，当时我们将 C 代码集成到其中，而不是调用一个进程。

进一步阅读

本章的笔记对于本书来说有些不寻常。这些笔记不是推荐读者进一步研究的论文，而是压倒性地建议阅读的代码库。数据并行迭代器非常出色，但需要一点时间来适应。

没有什么比阅读现有项目更有帮助了。对我来说，我认为每 1000 行源代码需要一个小时来理解透彻。这为下午的宁静时光提供了保障：

• rayon，可在github.com/rayon-rs/rayon找到。我们在本章中相当详细地讨论了这个 crate，但只是触及了它的表面。我强烈推荐有动力的读者阅读 ParallelIterator，并努力理解那里暴露的操作符。

• xsv，可在github.com/BurntSushi/xsv找到。安德鲁·加兰特（Andrew Gallant）目前负责一些最快的以文本为中心的 Rust 代码，xsv 也不例外。这个 crate 实现了一套用于非常快速、并行 CSV 查询和操作的工具集。之前讨论的 threadpool crate 驱动了整个系统。如果你对快速文本处理有抱负，并想看到线程池在其中的应用，那么阅读它是非常值得的。

• ripgrep，可在github.com/BurntSushi/xsv找到。安德鲁·加兰特的 ripgrep 是世界上最快的 grep 实现之一。读者可能会感兴趣的是，该实现没有使用任何现成的 threadpool crates 或 rayon。Ripgrep 为每次搜索启动一个结果打印线程，然后启动一个有界多线程来对文件执行实际搜索。每个搜索线程通过 MPSC 与打印线程通信结果，从而确保打印的结果不会被撕裂，搜索可以利用可用的机器 CPU。

• tokei，可在github.com/Aaronepower/tokei找到。世界上有许多源代码行数统计程序，但很少有像 Aaron Power 的 tokei 那样覆盖这么多语言或运行这么快。如果你对解析感兴趣，阅读其实现是很有价值的。但是，tokei 还特别利用了 rayon。在项目中，读者应该自己发现项目选择顺序 std 迭代器而不是 rayon 的并行迭代器的原因。然后，他们应该思考为什么做出这样的选择。

• i8080，可在github.com/Aaronepower/i8080找到。除了 tokei，Aaron Power 还用 Rust 编写了一个令人印象深刻的 Intel 8080 仿真器。MARS 是一个非常奇怪的机器，读者可能会在发现如何仿真实际的简单 CPU 时度过一段愉快的时光。

• QuickCheck：轻量级 Haskell 程序随机测试工具，2000 年，Koen Claessen 和 John Hughes。这篇论文介绍了 QuickCheck 工具用于 Haskell，并将基于属性的测试引入了世界。这里的研究建立在之前的随机测试工作之上，但新颖之处在于意识到计算机已经足够快，可以支持类型指导的生成，并在单页附录中提供实现。许多后续论文都基于这一篇来提高属性测试器的探测能力。

• Smallcheck 和 Lazy Smallcheck：小值自动穷举测试，2008 年，Colin Runciman、Matthew Naylor 和 Fredrik Lindblad。这篇论文直接受到了 Claessen 和 Hughes 工作的启发，但假设许多程序缺陷首先出现在小输入上。论文后半部分的 Lazy Smallcheck 讨论特别有趣。我在阅读时发现自己越来越有动力去实现一个 Prolog。

• 宏：Rust 参考，可在doc.rust-lang.org/reference/macros.html找到。Rust 中的宏使用处于一种奇怪的状态。它显然很有用，但当前的宏实现并不受欢迎，一个新宏系统正在逐渐取代它。同时，如果你想构建用于代码中的宏，你需要这个参考。

• C10K 问题，可在www.kegel.com/c10k.html找到。当这个页面首次出现在互联网上时，引起了广泛的讨论。讨论的问题是单个网络服务器如何处理 10,000 个活跃连接，并且以非失败的方式处理它们。作者指出了一些进一步阅读的资源，这些资源至今仍然有用，并讨论了当时最先进的操作系统，包括内核版本和新颖的轮询 API 的引入。尽管已经过时——多连接问题现在通常表述为 C1M——但它仍然是一篇优秀且信息丰富的读物。

• 《1994 年核心战标准草案的注释》 可在 corewar.co.uk/standards/icws94.htm 查阅。Corewars 是一款微妙的游戏，从汇编语言 Redcode 对机器的影响以及机器本身的功能来看。这份文档试图在 1994 年标准化这两者的行为。该标准未被接受——标准机构正在衰落——但提案文件非常清晰，甚至还附带了一个 MARS 的简要 C 语言实现。

第九章：FFI 和嵌入——结合 Rust 和其他语言

在本书的这一部分，我们基本上是独立地讨论了 Rust。Rust 被有意设计成可以通过其外部函数接口（FFI）调用外部编程语言，并且自身也可以嵌入。许多现代编程语言都提供了 FFI、易于嵌入或两者兼而有之。例如，Python 可以非常方便地调用具有 C 调用约定的库，并且只需稍加考虑就可以嵌入。Lua 是一种类似于 Python 的高级和垃圾回收语言，它有一个方便的 FFI，并且可以轻松嵌入。Erlang 有几个 FFI 接口，但 Erlang 本身并不容易嵌入到用户空间环境中。有趣的是，将 Erlang 编译成 RTOS 映像相当直接。

在本章中，我们将讨论在 Rust 中调用外部代码以及将 Rust 嵌入到外部编程语言中。我们将从扩展我们在第八章的末尾介绍的 corewars evolver 程序——feruscore——开始。您被鼓励在开始本章之前阅读该材料。在我们通过在内部嵌入 C MARS 模拟器来扩展 feruscore 之后，我们将转向从 C 程序中调用 Rust 函数。我们将展示如何将 Lua 嵌入到 Rust 系统中以方便脚本编写，并以将 Rust 嵌入到高级垃圾回收语言（Python 和 Erlang）中结束本章。

到本章结束时，我们将：

• 将上一节中的 feruscore 项目调整为包含 C 模拟器

• 展示了将 Lua 代码包含到 Rust 项目中的方法

• 展示了将 Rust 代码包含到 C 项目中的方法

• 展示了将 Rust 代码包含到 Python 项目中的方法

• 展示了将 Rust 代码包含到 Erlang/Elixir 项目中的方法

将 C 嵌入到 Rust 中——feruscore 不使用进程

当我们在上一章结束对 feruscore 的讨论时，我们已经构建了一个程序，可以通过模拟自然选择来发现 corewars 战士。这是通过将进化的战士写入磁盘，使用 Rust 的操作系统进程接口调用 pmars（事实上的标准 MARS）来竞争，以发现它们的相对适应性来完成的。我们使用了 Rayon（Rust 的非常方便的数据并行库）来在可用的 CPU 之间分配竞争的工作负载。不幸的是，实现相当慢。构建锦标赛选择标准可能比我们希望的更难表达——尽管我确信一定有一个聪明的读者会大幅改进这一点并让我感到惊讶。真正的痛点是将每个战士多次序列化到磁盘，重复分配相似的结构来建立每一轮，然后消耗 pmars 的分配和解析开销。正是这一步，调用外部程序来运行竞争，我们将在本章中解决。我们还将解决其他两个问题，因为，嗯，为什么不全力以赴呢？

并非 feruscore 的所有源代码都出现在本章中。其中一些在上一章中进行了深入讨论，一些——例如基准测试代码——将是书中已覆盖材料的重复。C 代码没有全部打印出来，因为它非常密集且非常长。你可以在本书的源代码库中找到完整的列表。

MARS C 接口

Corewars 是一款古老的比赛，现在有很多 MARS 的实现。pMARS，如我提到的，是事实上的标准，实现了 '94 ICWS 草案，并添加了后来的补充，例如新的指令和称为 p-space 的东西，我们在这里不会深入讨论。Corewars 从未是严肃的业务。现在在线上可用的许多 MARS 在过去几年中相互交换代码，编写时对正确性的关注程度不同，有时是为旧机器编写的，在研究实验室中，多处理是一个问题。大多数没有在其内部库接口和可执行消费者之间做出区分，就像 Rust 程序那样。一些幸运的少数被设计为嵌入式，或者至少是旧 MARS 代码库的提取，可以扩展。其中一些幸运的少数在其实现中不使用静态全局变量，并且可以嵌入到多处理环境中，例如 feruscore。

在 MARS 实现的传统大背景下，我们将从一个现有的、公有领域的 MARS 开始，将其精简为一个可管理的核心，并给它带来新的变化。具体来说，本章中引入的 feruscore 嵌入了一个 1.9.2 版本的 exhaust (corewar.co.uk/pihlaja/exhaust/)，这是 M. Joonas Pihlaja 在 2000 年代初编写的。Pihlaja 似乎从 pMARS 中提取了部分代码，尤其是在 exhaust 的主函数和解析函数周围。我们并不需要这些代码。我们需要的是模拟器。这意味着我们可以丢弃与解析相关的任何内容，以及为 exhaust 的main函数所需的所有支持代码。我们需要的提取代码位于 feruscore 项目的根目录下，在c_src/中。我们将嵌入的函数都实现在c_src/sim.c中。这些函数来自c_src/sim.h：

void sim_free_bufs(mars_t* mars);
void sim_clear_core(mars_t* mars);

int sim_alloc_bufs(mars_t* mars);
int sim_load_warrior(mars_t* mars, uint32_t pos, 
                     const insn_t* const code, uint16_t len);
int sim_mw(mars_t* mars, const uint16_t * const war_pos_tab,
           uint32_t *death_tab );

sim_alloc_bufs函数负责分配空白mars_t的内部存储，这是模拟所执行的结构体。sim_clear_core在回合之间清除mars_t，将核心内存设置为DAT，并重置任何战士队列。sim_load_warrior将战士加载到核心内存中，战士实际上只是一个指向包含指令的数组的指针—insn_t—并传递len长度。sim_mw运行模拟，从war_pos_tab读取战士位置，并在战士完全死亡时写入death_tab。

从 Rust 创建 C-structs

现在，我们如何从 Rust 调用这些函数？此外，我们如何创建mars_t或insn_t的实例？回想一下第三章，Rust 内存模型 – 所有权、引用和操作，Rust 允许对结构体的内存布局进行控制。具体来说，所有 Rust 结构体都是隐式地repr(Rust)，类型对齐到字节边界，结构体字段按编译器认为合适的方式进行排序，以及其他细节。我们还提到了结构体的repr(C)的存在，其中 Rust 将以与 C 相同的方式布局结构体的内存表示。现在，这些知识将得到应用。

我们将这样做。首先，我们将 C 代码编译成一个库，并将其链接到 feruscore。这是通过在项目根目录放置一个build.rs文件并使用 cc (crates.io/crates/cc) crate 来生成一个静态归档来完成的：

extern crate cc;

fn main() {
    cc::Build::new()
        .file("c_src/sim.c")
        .flag("-std=c11")
        .flag("-O3")
        .flag("-Wall")
        .flag("-Werror")
        .flag("-Wunused")
        .flag("-Wpedantic")
        .flag("-Wunreachable-code")
        .compile("mars");
}

当项目构建时，Cargo 会将libmars.a生成到target/目录下。但是，我们如何创建insn_t呢？我们复制了表示。本项目的 C 部分定义insn_t如下：

typedef struct insn_st {
  uint16_t a, b;
  uint16_t in;
} insn_t;

uint16_t a和uint16_t b是指令的a-字段和b-字段，其中uint16_t是指令中的OpCode、Modifier和Modes的压缩表示。项目的 Rust 部分定义指令如下：

#[derive(PartialEq, Eq, Copy, Clone, Debug, Default)]
#[repr(C)]
pub struct Instruction {
    a: u16,
    b: u16,
    ins: u16,
}

这是inst_t C 的确切布局。读者会注意到这与我们在上一章中看到的Instruction定义有很大不同。此外，请注意字段名并不重要，只有位表示。C 结构体在结构体的最后一个字段中调用，但在 Rust 中这是一个保留关键字，所以在 Rust 这边是ins。现在，ins字段发生了什么？回想一下，Mode枚举只有五个字段。我们实际上只需要三个位来编码一个模式，将枚举转换为数值表示。对于指令的其他组件也有类似的想法。ins字段的布局如下：

bit         15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
field       |-flags-| |–-opcode–-| |–mod-| |b-mode| |a-mode|

a 字段的Mode编码在位 0、1 和 2。b 字段的Mode在位 3、4 和 5，其他指令组件以此类推。最后两个位，14 和 15，编码了一个几乎总是为零的flag。非零标志是向模拟器指示非零指令是START指令——战士的第 0 条指令不一定是 MARS 首先执行的指令。这种紧凑的结构需要程序员做更多的工作来支持它。例如，Instruction不能再由程序员直接创建，而必须通过构建器构建。InstructionBuilder定义在src/instruction.rs中，如下所示：

pub struct InstructionBuilder {
    core_size: u16,
    ins: u16,
    a: u16,
    b: u16,
}

和往常一样，我们必须跟踪核心大小。构建构建器这个过程足够直接，到这个阶段为止：

impl InstructionBuilder {
    pub fn new(core_size: u16) -> Self {
        InstructionBuilder {
            core_size,
            ins: 0_u16,
            a: 0,
            b: 0,
        }
    }

将字段写入指令需要一点位操作。以下是如何写入一个Modifier：

    pub fn modifier(mut self, modifier: Modifier) -> Self {
        let modifier_no = modifier as u16;
        self.ins &= !MODIFIER_MASK;
        self.ins |= modifier_no << MODIFIER_MASK.trailing_zeros();
        self
    }

常量MODIFIER_MASK在源文件顶部的某个代码块中定义，与其他字段掩码一起：

const AMODE_MASK: u16 = 0b0000_0000_0000_0111;
const BMODE_MASK: u16 = 0b0000_0000_0011_1000;
const MODIFIER_MASK: u16 = 0b0000_0001_1100_0000;
const OP_CODE_MASK: u16 = 0b0011_1110_0000_0000;
const FLAG_MASK: u16 = 0b1100_0000_0000_0000;

注意到掩码中的相关位是 1 位。在InstructionBuilder::modifier中，我们使用&=操作符对掩码取反，然后将ins与掩码取反后的结果进行布尔与操作，将之前存在的Modifier清零。完成这些后，将编码为 u16 的Modifier左移，并布尔或操作到正确的位置。trailing_zeros()函数返回一个单词低端的连续零的总数，这是我们每个掩码需要左移的确切数量。那些在其他语言中做过位操作工作的读者可能会觉得这个过程非常简洁。我也这么认为。Rust 的整数显式二进制形式使得编写和后来理解掩码变得非常容易。常见的位操作和查询在每种基本整数类型上都有实现。非常有用。

OpCode布局有所变化。我们不使用repr(C)枚举，因为位表示并不重要。重要的是，由于这个枚举没有字段，所以它转换到的整数。在源代码中第一个映射到 0，第二个映射到 1，以此类推。C 代码在c_src/insn.h中定义操作码如下：

enum ex_op {
    EX_DAT,             /* must be 0 */
    EX_SPL,
    EX_MOV,
    EX_DJN,
    EX_ADD,
    EX_JMZ,
    EX_SUB,
    EX_SEQ,
    EX_SNE,
    EX_SLT,
    EX_JMN,
    EX_JMP,
    EX_NOP,
    EX_MUL,
    EX_MODM,
    EX_DIV,             /* 16 */
};

Rust 版本如下：

#[derive(PartialEq, Eq, Copy, Clone, Debug, Rand)]
pub enum OpCode {
    Dat,  // 0
    Spl,  // 1
    Mov,  // 2
    Djn,  // 3
    Add,  // 4
    Jmz,  // 5
    Sub,  // 6
    Seq,  // 7
    Sne,  // 8
    Slt,  // 9
    Jmn,  // 10
    Jmp,  // 11
    Nop,  // 12
    Mul,  // 13
    Modm, // 14
    Div,  // 15
}

其他指令组件已经稍微调整了一下，以应对 C 代码所需的变更。好消息是，这种表示形式比上一章中的表示形式更紧凑，并且应该保留，即使所有 C 代码都移植到 Rust 中，这也是我们稍后将要讨论的主题。但是——我将省略InstructionBuilder的完整定义，因为一旦你看过一组设置函数，你就已经看过了它们——所有这些位操作确实使得实现更难以看到，并且难以一眼纠正。指令模块现在有 QuickCheck 测试来验证所有字段是否正确设置，这意味着无论字段设置和重置多少次，它们都可以立即准备好。鼓励你自己检查 QuickCheck 测试。

高级理念是这样的——创建一个空的指令，然后在该指令上运行一系列变更订单——暂时将其移入指令构建器以允许修改——然后读取并确认变更的字段已变为所更改的值。这项技术与我们在其他地方之前看到的技术是一致的。

现在，关于那个mars_t呢？在c_src/sim.h中的 C 定义是：

typedef struct mars_st {
  uint32_t nWarriors;

  uint32_t cycles;
  uint16_t coresize;
  uint32_t processes;

  uint16_t maxWarriorLength;

  w_t* warTab;
  insn_t* coreMem;
  insn_t** queueMem;
} mars_t;

nWarriors字段设置模拟中将有多少战士，对于 feruscore 来说，总是两个周期，控制了如果两个战士都还活着，一个回合将需要多少周期才能结束，处理可用的最大进程数，maxWarriorLength显示战士可能的最大指令数。所有这些在上一章中或多或少都是熟悉的，只是在新编程语言中，并且有不同的名称。最后三个字段是指向数组的指针，并且对于模拟函数来说是私有的。这些是通过sim_alloc_bufs和sim_free_bufs分别分配和释放的。这个结构的 Rust 版本看起来是这样的，来自src/mars.rs：

#[repr(C)]
pub struct Mars {
    n_warriors: u32,
    cycles: u32,
    core_size: u16,
    processes: u32,
    max_warrior_length: u16,
    war_tab: *mut WarTable,
    core_mem: *mut Instruction,
    queue_mem: *const *mut Instruction,
}

这里唯一的新类型是WarTable。尽管我们的代码永远不会显式地操作战士表，但我们仍然必须与 C 兼容。WarTable的定义如下：

#[repr(C)]
struct WarTable {
    tail: *mut *mut Instruction,
    head: *mut *mut Instruction,
    nprocs: u32,
    succ: *mut WarTable,
    pred: *mut WarTable,
    id: u32,
}

我们可能可以只通过在Mars中将这些私有字段设置为mars_st中的void指针来解决这个问题，但这会减少项目 C 端的信息类型，并且这种方法可能会阻碍未来的移植工作。由于项目 Rust 端类型明确，因此考虑在 Rust 中重写 C 函数要容易得多。

调用 C 函数

现在我们可以创建具有 C 位布局的 Rust 结构，我们可以开始将内存传递到 C 中。重要的是要理解，这是一个固有的不安全活动。C 代码可能会以破坏 Rust 不变性的方式操作内存，而我们唯一能确保这不是真的方法是在事先审计 C 代码。这与模糊测试一样，我们也会进行。我们如何链接到libmars.a？一个小的extern块就可以做到，在src/mars.rs中：

#[link(name = "mars")]
extern "C" {
    fn sim_alloc_bufs(mars: *mut Mars) -> isize;
    fn sim_free_bufs(mars: *mut Mars) -> ();
    fn sim_clear_core(mars: *mut Mars) -> ();
    fn sim_load_warrior(mars: *mut Mars, pos: u32, 
                        code: *const Instruction, 
                        len: u16) -> isize;
    fn sim_mw(mars: *mut Mars, war_pos_tab: *const u16, 
              death_tab: *mut u32) -> isize;
}

使用 #[link(name = "mars")]，我们指示编译器链接到构建过程中生成的 libmars.a。如果我们正在链接到系统库，方法将是相同的。Rust Nomicon 部分关于 FFI 的内容——在本章末尾的 进一步阅读 部分中引用——链接到 libsnappy，例如。extern 块通知编译器，这些函数将需要使用 C ABI 调用，而不是 Rust 的。让我们将 sim_load_warrior 进行并排比较。以下是 C 版本：

int sim_load_warrior(mars_t* mars, uint32_t pos, 
                     const insn_t* const code, uint16_t len);

这是 Rust 版本：

fn sim_load_warrior(mars: *mut Mars, pos: u32, 
                    code: *const Instruction, 
                    len: u16) -> isize;

这些是相似的。尽管 Rust 可以免费获取代码的 const 注释，但 C 没有与 Rust 相同的可变性概念。我们通过使所有指令的查询函数都接受 &self 来增强了这一点。经验法则——除非 C 是 const-correct，否则你可能需要假设 Rust 需要 *mut。这并不总是正确的，但它可以节省很多麻烦。现在，关于这个概念，细心的读者可能会注意到，当我将 exhaust 的代码移植到 feruscore 时，我将其修改为使用 stdint.h。在未修改的代码中，pos 有无符号整型或 usize 类型。模拟器 C 代码假设 pos 至少有 32 位宽，因此显式转换为 32 位整数。这并不完全必要，但使用固定宽度类型是一种良好的做法，因为它们最小化了在 CPU 架构之间移动时的惊喜。

管理跨语言所有权

Rust 现在知道 C 函数了，并且我们已经将内部结构重新设计为使用 C 布局：现在是时候将操作 mars_t 的 C 函数与我们的 Mars 链接起来。因为我们正在 Rust 分配器和 C 分配器之间共享 Mars 的所有权，所以我们必须小心地将 Mars 结构体中的字段初始化为 null 指针，这些字段将由 C 拥有，如下所示：

impl MarsBuilder {
    pub fn freeze(self) -> Mars {
        let mut mars = Mars {
            n_warriors: 2,
            cycles: u32::from(self.cycles.unwrap_or(10_000)),
            core_size: self.core_size.unwrap_or(8_000),
            processes: self.processes.unwrap_or(10_000),
            max_warrior_length: self.max_warrior_length.unwrap_or(100),
            war_tab: ptr::null_mut(),
            core_mem: ptr::null_mut(),
            queue_mem: ptr::null_mut(),
        };
        unsafe {
            sim_alloc_bufs(&mut mars);
        }
        mars
    }

这个 MarsBuilder 是一个用于生成 Mars 的构建器模式。实现的其他部分按预期工作：

    pub fn core_size(mut self, core_size: u16) -> Self {
        self.core_size = Some(core_size);
        self
    }

    pub fn cycles(mut self, cycles: u16) -> Self {
        self.cycles = Some(cycles);
        self
    }

    pub fn processes(mut self, processes: u32) -> Self {
        self.processes = Some(processes);
        self
    }

    pub fn max_warrior_length(mut self, max_warrior_length: u16) -> Self {
        self.max_warrior_length = Some(max_warrior_length);
        self
    }
}

回到 MarsBuilder::freeze(self) -> Mars。这个函数创建一个新的 Mars，然后立即将其传递给 sim_alloc_bufs：

unsafe {
    sim_alloc_bufs(&mut mars);
}

&mut mars 自动转换为 *mut mars，正如我们从前几章所知，解引用原始指针是不安全的。它是 C 解引用原始指针的事实更是锦上添花。现在，让我们看一下 sim_alloc_bufs 并了解正在发生的事情。在 c_src/sim.c 中：

int sim_alloc_bufs(mars_t* mars) {
    mars->coreMem = (insn_t*)malloc(sizeof(insn_t) * mars->coresize);
    mars->queueMem = (insn_t**)malloc(sizeof(insn_t*) * 
                       (mars->nWarriors * mars->processes + 1));
    mars->warTab = (w_t*)malloc(sizeof(w_t)*mars->nWarriors);

    return (mars->coreMem
            && mars->queueMem
            && mars->warTab);
}

C 拥有的三个字段——coreMem、queueMem 和 warTab——是根据存储的结构的尺寸分配的，返回值是 malloc 返回值的布尔与，这是一种确定 malloc 是否曾经返回 NULL 的简便方法，这表示系统上没有更多的内存可用。如果我们决定向 Rust 结构体中添加一个新字段，而没有更新 C 结构体以反映这一变化，这些存储空间就会太小。最终，某个地方的代码会超出数组边界并崩溃。这可不是什么好事。

但是！我们刚刚从 Rust 调用了 C 代码。

让我们谈谈所有权问题。Mars 是一个结构，它既不完全由 Rust 拥有，也不完全由 C 拥有。这是可以接受的，并且也不少见，尤其是如果你正在部分（或完全）将 C 代码库移植到 Rust。这意味着我们必须小心处理 Drop：

impl Drop for Mars {
    fn drop(&mut self) {
        unsafe { sim_free_bufs(self) }
    }
}

正如我们在前面的章节中看到的，当使用原始内存时，我们必须显式地进行 Drop 操作。Mars 也不例外。这里的 sim_free_bufs 调用清理了 C 所拥有的内存，而 Rust 负责处理其余部分。如果清理更加困难——这种情况有时会发生——你必须小心避免在释放后解引用 C 所拥有的指针。sim_free_bufs 的实现如下：

void sim_free_bufs(mars_t* mars)
{
    free(mars->coreMem);
    free(mars->queueMem);
    free(mars->warTab);
}

运行模拟

剩下的工作就是运行模拟中的战士。在上一章中，Individual 负责管理自己的 pmars 进程。现在，Mars 将负责托管竞争对手，你可能已经从 C API 中了解到这一点。我们简单地没有在 Individual 中存储任何东西的空间，通过将竞争推入 Mars，我们可以避免在临时的 Mars 结构上发生分配波动。

之前绑定到 Individual 的完整函数现在已移动到 Mars：

impl Mars {
    /// Competes two Individuals at random locations
    ///
    /// The return of this function indicates the winner. 
    /// `Winner::Right(12)` will mean that the 'right' player 
    /// won 12 more rounds than did 'left'. This may mean they
    /// tied 40_000 times or maybe they only played 12 rounds 
    /// and right won each time.
    pub fn compete(&mut self, rounds: u16, left: &Individual, 
                   right: &Individual) -> Winner {
        let mut wins = Winner::Tie;
        for _ in 0..rounds {
            let core_size = self.core_size;
            let half_core = (core_size / 2) - self.max_warrior_length;
            let upper_core = core_size - self.max_warrior_length;
            let left_pos = thread_rng().gen_range(0, upper_core);
            let right_pos = if (left_pos + self.max_warrior_length) 
                               < half_core {
                thread_rng().gen_range(half_core + 1, upper_core)
            } else {
                thread_rng().gen_range(0, half_core)
            };
            wins = wins + self.compete_inner(left, left_pos, 
                                             right, right_pos);
        }
        tally_fitness(wins);
        BATTLES.fetch_add(1, Ordering::Relaxed);
        wins
    }

C API 要求我们计算战士的偏移量，并注意不要重叠它们。这里采取的方法是随机放置左边的 Individual，确定它是在核心的上部还是下部，然后放置右边的 Individual，同时注意不要将它们放置在核心的 end 之后。竞争的实际实现是 compete_inner：

    pub fn compete_inner(
        &mut self,
        left: &Individual,
        left_pos: u16,
        right: &Individual,
        right_pos: u16,
    ) -> Winner {
        let (left_len, left_code) = left.as_ptr();
        let (right_len, right_code) = right.as_ptr();

        let warrior_position_table: Vec<u16> = vec![left_pos, right_pos];
        let mut deaths: Vec<u32> = vec![u32::max_value(), 
                                        u32::max_value()];

我们调用 Individual::as_ptr() -> (u16, *const Instruction) 来获取个体的染色体及其长度的原始视图。没有这个，我们就无法将任何内容传递给 C 函数。warrior_position_table 通知 MARS 哪些指令是其竞争对手的起始点。我们可以在战士中搜索 START 标志，并将其放置在 warrior_position_table 中。这是一个留给读者的改进。死亡表将由模拟器代码填充。如果两个战士在竞争中同时死亡，数组将是 [0, 1]。死亡表用 u32::max_value() 填充，以便于区分无结果和结果。在开始竞争之前，我们必须清除模拟器——它可能充满了来自上次比赛的指令：

        unsafe {
            sim_clear_core(self);

如果你拉取 sim_clear_core 的实现，你会找到一个将 core_mem 设置为 0 的 memset 操作。回想一下，DAT 是 Instruction 枚举的第 0 个变体。与 pmars 不同，这个模拟器必须使用 DAT 作为默认指令，但它确实使得重置字段非常快速。sim_clear_core 还清理了进程队列和其他 C 所拥有的存储。加载战士的信息是一个将我们已计算的信息插入的过程：

            assert_eq!(
                0,
                sim_load_warrior(self, left_pos.into(), 
                                 left_code, left_len)
            );
            assert_eq!(
                0,
                sim_load_warrior(self, right_pos.into(), 
                                 right_code, right_len)
            );

如果结果是非零的，这表明发生了某些严重且无法恢复的错误。sim_load_warrior 是一个数组操作，将战士指令写入 core_mem 中的定义偏移量。如果我们想的话，完全可以使用 Rust 重新编写 sim_clear_core 和 sim_load_warrior 函数。最后，字段已清除且战士已加载，我们能够进行模拟：

            let alive = sim_mw(self, 
                               warrior_position_table.as_ptr(),     
                               deaths.as_mut_ptr());
            assert_ne!(-1, alive);
        }

sim_mw 函数返回模拟运行结束时剩余的战士总数。如果这个值是 -1，则表示发生了某些灾难性的、无法恢复的错误。

现在，因为我们有一个很好的类型系统可以与之玩耍，我们并不想用整数向量向用户返回结果。我们保留了看到的 Winner 类型

在上一章中，在返回之前进行快速转换：

        let left_dead = deaths[0] != u32::max_value();
        let right_dead = deaths[1] != u32::max_value();
        match (left_dead, right_dead) {
            (false, false) | (true, true) => Winner::Tie,
            (true, false) => Winner::Right(1),
            (false, true) => Winner::Left(1),
        }
    }
}

你可能已经注意到 Winner 实现了 Add，允许竞争信号战士赢得了多少轮。impl Add for Winner 也在 src/mars.rs 中，如果你好奇想看看它。作为对 Mars 的最终合理性测试，我们确认 Imp 会比其他结果更经常地输给 Dwarf：

#[cfg(test)]
mod tests {
    use super::*;
    use individual::*;

    #[test]
    fn imp_vs_dwarf() {
        let core_size = 8_000;
        let rounds = 100;
        let mut mars = MarsBuilder::default()
                           .core_size(core_size).freeze();
        let imp = ringers::imp(core_size);
        let dwarf = ringers::dwarf(core_size);
        let res = mars.compete(rounds, &imp, &dwarf);
        println!("RES: {:?}", res);
        match res {
            Winner::Left(_) | Winner::Tie => { 
                panic!("imp should lose to dwarf")
            },
            Winner::Right(_) => {}
        }
    }
}

回想一下，Imp 不能自杀，只能传播。Dwarf 以规律、递增的偏移量轰炸核心内存。因此，Imp 与 Dwarf 的竞争是一场 Imp 寻找 Dwarf 指令和 Dwarf 在 Imp 的路径上放下 DAT 的赛跑。

模糊测试模拟

在本章中，Feruscore 已被修改以包括 Rust 和通过 FFI 的原始内存访问。应负责的事情是模糊测试 Mars 并确保我们没有造成段错误。我们将使用 AFL，我们之前在 第二章 和 第五章 中讨论过，分别是 Sequential Rust Performance and Testing 和 Locks – Mutex, Condvar, Barriers, and RWLock。模糊测试目标是 src/bin/fuzz_target.rs。模糊测试的技巧在于确保稳定性。也就是说，如果某些输入被多次应用，导致多个路径出现，那么 AFL 真的无法完成其工作。在确定性系统中，模糊测试更有效率。我们小心地使 Mars::compete_inner 确定性，而 Mars::compete 使用随机性来确定战士的位置。因此，模糊测试将只通过 compete_inner。fuzz_target 的前言不包含任何新的 crate：

extern crate byteorder;
extern crate feruscore;

use byteorder::{BigEndian, ReadBytesExt};
use feruscore::individual::*;
use feruscore::instruction::*;
use feruscore::mars::*;
use std::io::{self, Cursor, Read};

记住，AFL 通过 stdin 传递一个字节切片，模糊测试目标是负责将该数组反序列化为对自己有意义的某种形式。我们将构建一个 Config 结构体：

#[derive(Debug)]
struct Config {
    pub rounds: u16,
    pub core_size: u16,
    pub cycles: u16,
    pub processes: u16,
    pub max_warrior_length: u16,
    pub left_chromosome_size: u16,
    pub right_chromosome_size: u16,
    pub left: Individual,
    pub right: Individual,
    pub left_pos: u16,
    pub right_pos: u16,
}

希望这些领域对您来说都很熟悉。rounds、core_size、cycles 和 processes 每个都会影响 MARS 环境。max_warrior_length、left_chromosome_size 和 right_chromosome_size 影响将要相互竞争的两个个体。left 和 right 是那些 Individual 实例。left_pos 和 right_pos 设置战士将在 MARS 核心内存中的位置。我们从字节切片反序列化出的数字不一定总是完全合理，因此需要一些清理工作，如下所示：

impl Config {
    pub fn new(rdr: &mut Cursor<Vec<u8>>) -> io::Result<Config> {
        let rounds = (rdr.read_u16::<BigEndian>()? % 1000).max(1);
        let core_size = (rdr.read_u16::<BigEndian>()? % 24_000).max(256);
        let cycles = (rdr.read_u16::<BigEndian>()? % 10_000).max(100);
        let processes = (rdr.read_u16::<BigEndian>()? % 1024).max(2);
        let max_warrior_length = (rdr.read_u16::<BigEndian>()? % 256).max(4);
        let left_chromosome_size = (rdr.read_u16::<BigEndian>()? 
                                       % max_warrior_length).max(2);
        let right_chromosome_size = (rdr.read_u16::<BigEndian>()? 
                                        % max_warrior_length).max(2);

例如，0 轮次没有任何意义，所以我们说至少必须有一轮。同样，我们需要两个进程，至少希望有四个战士指令，等等。创建左右战士的问题在于将字节读取器传递给 Config::mk_individual：

        let left = Config::mk_individual(rdr, 
                                         max_warrior_length,
                                         left_chromosome_size, 
                                         core_size)?;
        let right =
            Config::mk_individual(rdr, 
                                  max_warrior_length, 
                                  right_chromosome_size, 
                                  core_size)?;

Config::mk_individual 将反序列化到 InstructionBuilder。整个事情有点尴尬。虽然我们可以将无字段的枚举转换为整数，但无法在没有一些复杂的匹配语句的情况下，从整数转换到无字段的枚举：

    fn mk_individual(
        rdr: &mut Cursor<Vec<u8>>,
        max_chromosome_size: u16,
        chromosome_size: u16,
        core_size: u16,
    ) -> io::Result<Individual> {
        assert!(chromosome_size <= max_chromosome_size);
        let mut indv = IndividualBuilder::new();
        for _ in 0..(chromosome_size as usize) {
            let builder = InstructionBuilder::new(core_size);
            let a_field = rdr.read_i8()?;
            let b_field = rdr.read_i8()?;
            let a_mode = match rdr.read_u8()? % 5 {
                0 => Mode::Direct,
                1 => Mode::Immediate,
                2 => Mode::Indirect,
                3 => Mode::Decrement,
                _ => Mode::Increment,
            };
            let b_mode = match rdr.read_u8()? % 5 {
                0 => Mode::Direct,
                1 => Mode::Immediate,
                2 => Mode::Indirect,
                3 => Mode::Decrement,
                _ => Mode::Increment,
            };

在这里，我们已经建立了 InstructionBuilder 并从字节切片中读取了 a 场和 b 场的 Mode。如果添加了字段，我们就必须通过这里来更新模糊测试代码。这真是个麻烦事。以相同的方式读取 Modifier：

            let modifier = match rdr.read_u8()? % 7 {
                0 => Modifier::F,
                1 => Modifier::A,
                2 => Modifier::B,
                3 => Modifier::AB,
                4 => Modifier::BA,
                5 => Modifier::X,
                _ => Modifier::I,
            };

读取 OpCode 也是如此：

            let opcode = match rdr.read_u8()? % 16 {
                0 => OpCode::Dat,   // 0
                1 => OpCode::Spl,   // 1
                2 => OpCode::Mov,   // 2
                3 => OpCode::Djn,   // 3
                4 => OpCode::Add,   // 4
                5 => OpCode::Jmz,   // 5
                6 => OpCode::Sub,   // 6
                7 => OpCode::Seq,   // 7
                8 => OpCode::Sne,   // 8
                9 => OpCode::Slt,   // 9
                10 => OpCode::Jmn,  // 10
                11 => OpCode::Jmp,  // 11
                12 => OpCode::Nop,  // 12
                13 => OpCode::Mul,  // 13
                14 => OpCode::Modm, // 14
                _ => OpCode::Div,   // 15
            };

生成指令很简单，多亏了这里使用的构建器模式：

            let inst = builder
                .a_field(a_field)
                .b_field(b_field)
                .a_mode(a_mode)
                .b_mode(b_mode)
                .modifier(modifier)
                .opcode(opcode)
                .freeze();
            indv = indv.push(inst);
        }
        Ok(indv.freeze())
    }

回到 Config::new，我们创建左右位置：

        let left_pos =
            Config::adjust_pos(core_size, 
                               rdr.read_u16::<BigEndian>()?, 
                               max_warrior_length);
        let right_pos =
            Config::adjust_pos(core_size, 
                               rdr.read_u16::<BigEndian>()?, 
                               max_warrior_length);

adjust_pos 函数是一件小事，目的是确保战士的位置在合理的范围内：

    fn adjust_pos(core_size: u16, mut pos: u16, space: u16) -> u16 {
        pos %= core_size;
        if (pos + space) > core_size {
            let past = (pos + space) - core_size;
            pos - past
        } else {
            pos
        }
    }

战士与这个计算重叠是完全可能的。这是可以的。我们进行模糊测试的雄心壮志不是检查程序的逻辑，而是寻找崩溃。实际上，如果两个战士重叠导致崩溃，这是我们必须要知道的事实。Config::new 的结束相当直接：

        Ok(Config {
            rounds,
            core_size,
            cycles,
            processes,
            max_warrior_length,
            left_chromosome_size,
            right_chromosome_size,
            left,
            right,
            left_pos,
            right_pos,
        })
    }

在所有这些之后，fuzz_target 的主函数是最小的：

fn main() {
    let mut input: Vec<u8> = Vec::with_capacity(1024);
    let result = io::stdin().read_to_end(&mut input);
    if result.is_err() {
        return;
    }
    let mut rdr = Cursor::new(input);
    if let Ok(config) = Config::new(&mut rdr) {
        let mut mars = MarsBuilder::default()
            .core_size(config.core_size)
            .cycles(config.cycles)
            .processes(u32::from(config.processes))
            .max_warrior_length(config.max_warrior_length as u16)
            .freeze();
        mars.compete_inner(
            &config.left,
            config.left_pos,
            &config.right,
            config.right_pos,
        );
    }
}

Stdin 被捕获并从它构建了一个 Cursor，我们将其传递给 Config::new，如前所述。生成的 Config 用于驱动 MarsBuilder，然后 Mars 就是两个可能重叠或可能不重叠的模糊测试 Individual 实例竞争的舞台。记住，在运行 AFL 之前，一定要运行 cargo afl build——发布版，而不是 cargo build ——发布版。两者都可以工作，但第一个在发现崩溃方面要快得多，因为 AFL 的仪器将内联在可执行文件中。我发现，即使是一个单独的实例 cargo afl fuzz -i /tmp/in -o /tmp/out target/release/fuzz_target 也能以不错的速度完成 AFL 循环。代码中分支不多，因此 AFL 要探索的路径也少。

feruscore 可执行文件

最后要介绍的是src/bin/feruscore.rs。仔细的读者会注意到，到目前为止，实现中几乎没有使用 rayon。实际上，在这个版本中并没有使用 rayon。以下是项目的完整Cargo.toml：

[package]
name = "feruscore"
version = "0.2.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
rand = "0.4"
rand_derive = "0.3"
libc = "0.2.0"
byteorder = "1.0"
num_cpus = "1.0"

[build-dependencies]
cc = "1.0"

[dev-dependencies]
quickcheck = "0.6"
criterion = "0.2"

[[bench]]
name = "mars_bench"
harness = false

[[bin]]
name = "feruscore"

[[bin]]
name = "fuzz_target"

如本章开头所述，feruscore 除了调用操作系统进程外，还存在两个问题：相似结构的重复分配和对锦标赛的较差控制。从某种角度看，比较Individual的适应性是一个排序函数。Rayon 确实具有并行排序能力，ParallelSliceMut<T: Send>::par_sort(&mut self)，其中T: Ord。我们可以利用这一点，为Individual定义一个Ord，每次比较都会分配一个新的Mars。然而，许多微小的分配会严重影响速度。一个线程本地的Mars可以将这个数量减少到每个线程一个分配，但这样我们仍然放弃了一些控制。例如，如果不检查 rayon 的源代码，我们能否确定种群块的大小大致相等？通常情况下，这并不是一个问题，但对我们来说却是。Rayon 要求我们执行折叠和减少步骤，这也是我们不需要做的工作，如果我们调整我们的目标的话。

处理并行遗传算法的一种常见方法，也是我们现在要采用的方法，是创建岛屿，这些岛屿并行进行进化。用户设置一个全局种群，这个种群被分配到岛屿之间，线程被分配到岛屿以模拟一定数量的代。在达到这一代数的限制后，岛屿种群被合并、打乱并重新分配到岛屿。这有助于减少跨线程通信，这可能会带来缓存局部性问题。

src/bin/feruscore.rs的序言部分很简单：

extern crate feruscore;
extern crate num_cpus;
extern crate rand;

use feruscore::individual::*;
use feruscore::mars::*;
use rand::{thread_rng, Rng};
use std::fs::{self, DirBuilder, File};
use std::io::{self, BufWriter};
use std::path::{Path, PathBuf};
use std::sync::atomic::{AtomicUsize, Ordering};
use std::sync::mpsc;
use std::{thread, time};

与上一章相比，配置和报告的全局变量有所减少：

// configuration
const POPULATION_SIZE: usize = 1_048_576 / 8; 
const CHROMOSOME_SIZE: u16 = 100;
const CORE_SIZE: u16 = 8000;
const GENE_MUTATION_CHANCE: u32 = 100;
const ROUNDS: u16 = 100;

// reporting
static GENERATIONS: AtomicUsize = AtomicUsize::new(0);

report函数几乎与上一章相同，只是要读取的原子变量少了一些。检查点也几乎完全相同。为了节省空间，我们将跳过重新打印这两个函数。新的内容是sort_by_tournament：

fn sort_by_tournament(mars: &mut Mars, 
                      mut population: Vec<Individual>) 
    -> Vec<Individual> 
{
    let mut i = population.len() - 1;
    while i >= (population.len() / 2) {
        let left_idx = thread_rng().gen_range(0, i);
        let mut right_idx = left_idx;
        while left_idx == right_idx {
            right_idx = thread_rng().gen_range(0, i);
        }
        match mars.compete(ROUNDS, 
                           &population[left_idx], 
                           &population[right_idx]) 
        {
            Winner::Right(_) => {
                population.swap(i, right_idx);
            }
            Winner::Left(_) => {
                population.swap(i, left_idx);
            }
            Winner::Tie => {}
        }
        i -= 1;
    }
    population
}

这个函数根据传递的Mars内部竞争的结果对种群进行排序。读者会注意到，这并不是一个真正的排序，因为最后一个元素是最适应的，但最后一个元素是第一个锦标赛的获胜者，倒数第二个是第二个锦标赛的获胜者，以此类推。只有population.len() / 2个竞争进行，产生的冠军与精确按适应性排序的种群相比具有优势。鼓励读者尝试自己实现sort_by_tournament。现在，让我们看看main函数：

fn main() {
    let mut out_recvs = Vec::with_capacity(num_cpus::get());
    let mut in_sends = Vec::with_capacity(num_cpus::get());

    let total_children = 128;

    let thr_portion = POPULATION_SIZE / num_cpus::get();
    for _ in 0..num_cpus::get() {
        let (in_snd, in_rcv) = mpsc::sync_channel(1);
        let (out_snd, out_rcv) = mpsc::sync_channel(1);
        let mut population: Vec<Individual> = (0..thr_portion)
            .into_iter()
            .map(|_| Individual::new(CHROMOSOME_SIZE))
            .collect();
        population.pop();
        population.pop();
        population.push(ringers::imp(CORE_SIZE));
        population.push(ringers::dwarf(CORE_SIZE));
        let _ = thread::spawn(move || island(in_rcv, 
                                             out_snd, 
                                             total_children));
        in_snd.send(population).unwrap();
        in_sends.push(in_snd);
        out_recvs.push(out_rcv);
    }

在 feruscore 运行中岛屿的总数将根据系统上可用的 CPU 数量而变化。每个岛屿都会创建两个同步的 MPSC 通道，一个用于主线程将种群推入工作线程，另一个用于工作线程将种群推回主线程。实现中称这些为in_*和out_*发送者和接收者。你可以再次看到，我们正在构建一个由随机Individual战士组成的种群并将他们推入其中，尽管岛屿种群不是POPULATION_SIZE，而是由可用 CPU 数量均匀分割的POPULATION_SIZE。在岛屿线程拥有种群后，启动报告线程，主要是为了避免 UI 垃圾信息：

    let _ = thread::spawn(report);

报告函数与上一章中关于 feruscore 的讨论大致相同，为了简洁起见，这里不再列出。

main函数的最后一段是重组循环。当岛屿线程完成竞赛后，它们将写入它们的输出发送者，该发送者会被重组循环拾取：

    let mut mars = MarsBuilder::default().core_size(CORE_SIZE).freeze();
    let mut global_population: Vec<Individual> = 
        Vec::with_capacity(POPULATION_SIZE);
    loop {
        for out_rcv in &mut out_recvs {
            let mut pop = out_rcv.recv().unwrap();
            global_population.append(&mut pop);
        }

一旦所有岛屿合并在一起，整个种群就会被打乱：

        assert_eq!(global_population.len(), POPULATION_SIZE);
        thread_rng().shuffle(&mut global_population);

这样，一代就完成了。我们checkpoint，这次进行了一次额外的锦标赛，从全局种群中拉取保存的优胜者：

        let generation = GENERATIONS.fetch_add(1, Ordering::Relaxed);
        if generation % 100 == 0 {
            global_population = sort_by_tournament(&mut mars, 
                                                   global_population);
            checkpoint(generation, &global_population)
                .expect("could not checkpoint");
        }

最后，种群被重新分割并发送到岛屿线程：

        let split_idx = global_population.len() / num_cpus::get();

        for in_snd in &mut in_sends {
            let idx = global_population.len() - split_idx;
            let pop = global_population.split_off(idx);
            in_snd.send(pop).unwrap();
        }
    }
}

现在，岛屿在做什么？嗯，它是一个无限循环，从种群分配接收器中提取：

fn island(
    recv: mpsc::Receiver<Vec<Individual>>,
    snd: mpsc::SyncSender<Vec<Individual>>,
    total_children: usize,
) -> () {
    let mut mars = MarsBuilder::default().core_size(CORE_SIZE).freeze();

    while let Ok(mut population) = recv.recv() {

现在在循环上方分配了一个Mars，这意味着我们将在每个 feruscore 运行中只进行num_cpu::get()次这种结构的分配。也请记住，当通道中没有数据时，Receiver::recv会阻塞，因此岛屿线程在没有工作可做时不会消耗 CPU。循环的内部应该很熟悉。首先，将Individual战士放入竞赛：

        // tournament, fitness and selection of parents
        population = sort_by_tournament(&mut mars, population);

通过从种群中选取高排名成员并产生两个子代到种群的低端，直到达到每代所需子代总数，来完成繁殖：

        // reproduce
        let mut child_idx = 0;
        let mut parent_idx = population.len() - 1;
        while child_idx < total_children {
            let left_idx = parent_idx;
            let right_idx = parent_idx - 1;
            parent_idx -= 2;

            population[child_idx] = population[left_idx]
                                    .reproduce(&population[right_idx]);
            child_idx += 1;
            population[child_idx] = population[left_idx]
                                    .reproduce(&population[right_idx]);
            child_idx += 1;
        }

在这个实现中，我们还在新引入的子代之前引入了随机新的种群成员：

        for i in 0..32 {
            population[child_idx + i] = Individual::new(CHROMOSOME_SIZE)
        }

随机注入可以帮助抑制种群中的过早收敛。记住，模拟进化是一种状态空间搜索。还有一点变化是，种群中的所有成员都有突变的机会：

        // mutation
        for indv in population.iter_mut() {
            indv.mutate(GENE_MUTATION_CHANCE);
        }

最后，我们将种群推回重组线程，对种群进行了彻底的处理：

        snd.send(population).expect("could not send");
    }
}

在这里进行的所有更改——减少小分配、每代减少竞赛总数、移除 pmars 解析及 spawn 开销——使得实现速度大幅提升。回想一下，上一章中的实现难以达到每秒 500 场竞赛——或者如 UI 所示为BATTLES——的峰值。以下是我在最近一次八小时运行中得到的报告诊断：

GENERATION(5459):
    RUNTIME (sec):  31248
    BATTLES:        41181
       BATTLES/s:   14340
    FITNESS:
        00...10:    151
        11...20:    2
        21...30:    0
        31...40:    1
        41...50:    0
        51...60:    0
        61...60:    2
        71...70:    1
        81...80:    0
        91...100:   41024

这是在一个 8,000 大小核心内存上的每秒 14,000 次战斗，或者大约每小时 650 代。仍然不是特别快，但足够你在一段时间后开始产生相当平庸的玩家。减少核心内存大小将提高运行时间，限制战士的最大长度也是如此。对构建更好的进化器感兴趣的人应该调查不同的评估适应度的方式，引入更多的铃声，并看看将 sim_mw 移植到 Rust 中是否会提高运行时间。这个模拟器不支持 pMARS 所有的指令范围，所以这也是一个改进的领域。

我很乐意听听你的想法。

将 Lua 集成到 Rust 中

本书讨论的许多程序都使用一个 报告 线程来通知用户程序的运行行为。这些报告函数都使用 Rust 编码，是可执行文件中不变的部分。但是，如果我们想让最终用户能够提供他们自己的报告例程呢？或者，考虑一下本书之前讨论过的 cernan 项目 (crates.io/crates/cernan)，它支持一个 可编程过滤器，这是一个在线数据流过滤器，最终用户可以在不更改 cernan 二进制文件的情况下对其进行编程。你是如何完成这个技巧的？

一个常见的答案，不仅在 Rust 中，在许多编译语言中也是如此，就是嵌入一个 Lua 解释器 (www.lua.org/) 并在启动时读取用户程序。事实上，这是一个如此常见的答案，以至于在 crates 生态系统中有许多 Lua 集成可供选择。在这里我们将使用 rlua (crates.io/crates/rlua)，因为它是一个安全的选择，并且项目文档非常好。其他 Lua 集成适合不同的目标。例如，Cernan 使用不同的、不一定安全的嵌入，因为我们需要允许最终用户定义他们自己的函数。

在上一章中，我们编写了一个名为 sniffer 的项目，其目的是三方面的——在接口上收集以太网数据包，报告它们，并将以太网数据包回显。让我们将这个程序改编一下，让用户能够通过自定义脚本来决定如何报告。项目的 Cargo.toml 文件略有不同，包括包含 rlua 依赖项并删除了线程密集型替代可执行文件：

[package]
name = "sniffer"
version = "0.2.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
pnet = "0.21"
rlua = "0.13"

[[bin]]
name = "sniffer"

在 src/bin/sniffer.rs 中定义的 sniffer 程序的前置部分对我们来说并没有惊喜：

extern crate pnet;
extern crate rlua;

use pnet::datalink::Channel::Ethernet;
use pnet::datalink::{self, DataLinkReceiver, MacAddr, 
                     NetworkInterface};
use pnet::packet::ethernet::{EtherType, EthernetPacket};
use rlua::{prelude, Function, Lua};
use std::fs::File;
use std::io::{prelude::*, BufReader};
use std::path::Path;
use std::sync::atomic::{AtomicUsize, Ordering};
use std::sync::mpsc;
use std::{env, thread};

我们从 rlua 库中导入 Function 和 Lua，但这基本上就是所有新内容。SKIPPED_PACKETS 和 Payload 的细节没有改变：

static SKIPPED_PACKETS: AtomicUsize = AtomicUsize::new(0);

#[derive(Debug)]
enum Payload {
    Packet {
        source: MacAddr,
        destination: MacAddr,
        kind: EtherType,
    },
    Pulse(u64),
}

我已经在这个例子中移除了以太网数据包的回显，因为在繁忙的以太网网络上这样做并不一定是一件好事。因此，watch_interface 比以前更加简洁：

fn watch_interface(mut rx: Box<DataLinkReceiver>, snd: mpsc::SyncSender<Payload>) {
    loop {
        match rx.next() {
            Ok(packet) => {
                let packet = EthernetPacket::new(packet).unwrap();

                let payload: Payload = Payload::Packet {
                    source: packet.get_source(),
                    destination: packet.get_destination(),
                    kind: packet.get_ethertype(),
                };
                if snd.try_send(payload).is_err() {
                    SKIPPED_PACKETS.fetch_add(1, Ordering::Relaxed);
                }
            }
            Err(e) => {
                panic!("An error occurred while reading: {}", e);
            }
        }
    }
}

timer 函数也没有改变：

fn timer(snd: mpsc::SyncSender<Payload>) -> () {
    use std::{thread, time};
    let one_second = time::Duration::from_millis(1000);

    let mut pulses = 0;
    loop {
        thread::sleep(one_second);
        snd.send(Payload::Pulse(pulses)).unwrap();
        pulses += 1;
    }
}

main函数现在接收一个额外的参数，目的是要传递给 Lua 函数的磁盘路径：

fn main() {
    let interface_name = env::args().nth(1).unwrap();
    let pulse_fn_file_arg = env::args().nth(2).unwrap();
    let pulse_fn_file = Path::new(&pulse_fn_file_arg);
    assert!(pulse_fn_file.exists());
    let interface_names_match = |iface: &NetworkInterface| {
        iface.name == interface_name
    };

    // Find the network interface with the provided name
    let interfaces = datalink::interfaces();
    let interface = interfaces
        .into_iter()
        .filter(interface_names_match)
        .next()
        .unwrap();

该函数旨在处理从计时器线程传入的Payload::Pulse。上一章中的收集函数不再存在。为了实际使用用户提供的函数，我们必须通过rlua::Lua::new()创建一个新的 Lua 虚拟机，然后将函数加载到其中，如下所示：

    let lua = Lua::new();
    let pulse_fn = eval(&lua, pulse_fn_file, Some("pulse")).unwrap();

eval函数简短，主要与从磁盘读取有关：

fn eval<'a>(lua: &'a Lua, path: &Path, name: Option<&str>) 
    -> prelude::LuaResult<Function<'a>> 
{
    let f = File::open(path).unwrap();
    let mut reader = BufReader::new(f);

    let mut buf = Vec::new();
    reader.read_to_end(&mut buf).unwrap();
    let s = ::std::str::from_utf8(&buf).unwrap();

    lua.eval(s, name)
}

那里的特定于 Lua 的部分是lua.eval(s, name)。它评估从磁盘读取的 Lua 代码，并返回一个函数，这是一个 Rust 可调用的 Lua 片段。Lua 源中提供的任何用户名称都被忽略，名称的存在是为了在 Rust 端添加错误消息的上下文。rlua 在其 Rust API 中不公开loadfile，尽管其他 Lua 嵌入确实如此。

main函数的下一部分基本上没有变化，尽管包缓冲通道已从 10 个元素增加到100：

    let (snd, rcv) = mpsc::sync_channel(100);

    let timer_snd = snd.clone();
    let _ = thread::spawn(move || timer(timer_snd));

    let _iface_handler = match datalink::channel(&interface, 
                                                 Default::default()) 
    {
        Ok(Ethernet(_tx, rx)) => {
            let snd = snd.clone();
            thread::spawn(|| watch_interface(rx, snd))
        }
        Ok(_) => panic!("Unhandled channel type"),
        Err(e) => panic!(
            "An error occurred when creating the datalink channel: {}",
            e
        ),
    };

现在，事情将要发生变化。首先，我们创建三个 Lua 表格来存储Payload::Packet的组件：

    let destinations = lua.create_table().unwrap();
    let sources = lua.create_table().unwrap();
    let kinds = lua.create_table().unwrap();

在上一章中，我们使用了三个HashMap，但现在，我们需要能够轻松传递给 Lua 的东西。主线程负责收集Payload实例的角色，这是收集函数曾经扮演的角色：收集Payload实例。这节省了一个线程，意味着我们不需要仔细安排发送 Lua 虚拟机跨线程边界：

    while let Ok(payload) = rcv.recv() {
        match payload {
            Payload::Packet {
                source,
                destination,
                kind,
            } => {
                let d_cnt = destinations
                                .get(destination.to_string())
                                .unwrap_or(0);
                destinations
                    .set(destination.to_string(), d_cnt + 1)
                    .unwrap();

                let s_cnt = sources.get(source.to_string()).unwrap_or(0);
                sources.set(source.to_string(), s_cnt + 1).unwrap();

                let k_cnt = kinds.get(kind.to_string()).unwrap_or(0);
                kinds.set(kind.to_string(), k_cnt + 1).unwrap();
            }

在这里，我们已经开始从接收器中提取有效载荷，并处理跨过来的Payload::Packets。注意我们在这个循环之前创建的表格现在正在被填充。同样的基本聚合操作正在发挥作用；持续计算进入的Packet组件。一个更有冒险精神的读者可能会扩展这个程序，允许 Lua 端构建自己的聚合。现在剩下的只是处理Payload::Pulse：

            Payload::Pulse(id) => {
                let skipped_packets = SKIPPED_PACKETS
                                      .swap(0, Ordering::Relaxed);
                pulse_fn
                    .call::<_, ()>((
                        id,
                        skipped_packets,
                        destinations.clone(),
                        sources.clone(),
                        kinds.clone(),
                    ))
                    .unwrap()
            }
        }
    }
}

之前创建的pulse_fn函数使用四个参数调用——脉冲 ID、SKIPPED_PACKETS和聚合表格。我们预计pulse_fn不会有任何返回值，因此有<_, ()>部分。这个版本的嗅探器包括一个示例包函数，定义在examples/pulse.lua中：

function (id, skipped_packets, dest_tbl, src_tbl, kind_tbl)
   print("ID: ", id)
   print("SKIPPED PACKETS: ", skipped_packets)
   print("DESTINATIONS:")
   for k,v in pairs(dest_tbl) do
      print(k, v)
   end
   print("SOURCES:")
   for k,v in pairs(src_tbl) do
      print(k, v)
   end
   print("KINDS:")
   for k,v in pairs(kind_tbl) do
      print(k, v)
   end
end

读者会注意到它基本上与之前收集函数所做的工作相同。运行嗅探器的工作方式与之前相同。确保执行cargo build --release然后：

> ./target/release/sniffer en0 examples/pulse.lua
ID:     0
SKIPPED PACKETS:    0
DESTINATIONS:
5c:f9:38:8b:4a:b6   11
8c:59:73:1d:c8:73   16
SOURCES:
5c:f9:38:8b:4a:b6   16
8c:59:73:1d:c8:73   11
KINDS:
Ipv4    27
ID:     1
SKIPPED PACKETS:    0
DESTINATIONS:
5c:f9:38:8b:4a:b6   14
8c:59:73:1d:c8:73   20
SOURCES:
5c:f9:38:8b:4a:b6   20
8c:59:73:1d:c8:73   14
KINDS:
Ipv4    34

注意分配的读者会注意到这里有很多克隆操作。这是真的。主要的编译是 Lua 的 GC 的互操作性。安全的 Rust 接口必须假设传递给 Lua 的数据将被垃圾回收。但是，Lua 支持用户数据的概念，程序员将不透明的数据块与 Lua 函数关联以操作它。Lua 还支持轻量级用户数据，它与用户数据非常相似，只是轻量级变体与内存的指针相关联。RLua 中的 UserData 类型做得相当不错，有雄心的读者可以构建一个实现UserData的PacketAggregation类型，以避免所有克隆操作。

将高级语言与系统语言结合通常是一场在内存管理复杂性、最终用户负担和初始编程难度之间的权衡游戏。rlua 在这些权衡中做得非常出色。像 mond 这样的东西在 cernan 中使用，在这方面做得不那么好，但使用上更加灵活。

嵌入 Rust

到目前为止，我们已经看到了如何将 C 和 Lua 嵌入 Rust。但是，如果你想要将 Rust 与其他编程语言结合使用呢？这样做是一种非常实用的技术，可以提高解释型语言的运行时性能，实现内存安全的扩展，这在以前你可能需要使用 C 或 C++。如果你的目标高级语言在并发嵌入方面有困难，Rust 则是一个更大的优势。Python 程序在这方面表现不佳——至少是那些在 CPython 或 PyPy 上实现的——因为全局解释器锁（一个内部互斥锁，锁定对象的字节码）。例如，将大量数据的计算任务卸载到 Rust + Rayon 扩展中，既可以简化编程，又可以提高计算速度。

好吧，太棒了。我们如何实现这类事情呢？Rust 的方法很简单：如果你可以嵌入 C，你就可以嵌入 Rust。

进入 C

让我们在 C 中嵌入一些 Rust。quantiles 库（crates.io/crates/quantiles）——在第四章中讨论过，Sync 和 Send——Rust 并发的基石——实现了在线汇总算法。这些算法在产生错误结果方面很容易出错，但更常见的是存储比严格必要更多的点。在 quantiles 中投入了大量工作以确保实现的算法接近理论上的最小存储需求，因此对于 C 中的在线汇总重用这个库而不是重新做所有这些工作是有意义的。

具体来说，让我们将quantiles::ckms::CKMS<f32>暴露给 C (docs.rs/quantiles/0.7.1/quantiles/ckms/struct.CKMS.html)。由于 C 在类型中缺乏任何泛型方式，我们必须使类型具体化，但这没关系。

Rust 方面

在Cargo.toml文件中有一些新内容需要讨论：

[package]
name = "embed_quantiles"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]
quantiles = "0.7"

[lib]
name = "embed_quantiles"
crate-type = ["staticlib"]

特别注意，我们正在构建embed_quantiles库，使用crate-type = ["staticlib"]。这意味着什么？Rust 编译器能够进行许多种链接，通常它们都是隐式的。例如，二进制文件是crate-type = ["bin"]。有一个长长的不同链接类型的列表，我已经在进一步阅读部分中包含了它们。鼓励感兴趣的读者查阅。我们希望在这里生成一个静态链接库，否则每个试图使用embed_quantiles的 C 程序员都需要在他们的系统上安装 Rust 的共享库。这……并不理想。一个staticlibcrate 将存档 Rust 代码需要的 Rust 标准库的所有部分。然后，这个存档可以像平常一样链接到 C。

好的，现在，如果我们打算生成一个 C 可以调用的静态存档，我们必须导出 Rust 函数以 C ABI。换句话说，我们必须在 Rust 之上套上一层 C 的皮肤。C++程序员会熟悉这种策略。这个项目中的唯一一个 Rust 文件是src/lib.rs，其前导部分可能正如你所预期的那样：

extern crate quantiles;

use quantiles::ckms::CKMS;

我们已经引入了分位数库并导入了CKMS。没什么大不了的。不过，看看这个：

#[no_mangle]
pub extern "C" fn alloc_ckms(error: f64) -> *mut CKMS<f32> {
    let ckms = Box::new(CKMS::new(error));
    Box::into_raw(ckms)
}

嘿！有一大堆新东西。首先，#[no_mangle]？静态库必须导出一个符号供链接器使用，以便进行链接。这些符号是函数、静态变量等等。通常，Rust 可以自由地篡改符号的名称以包含信息，比如模块位置，或者实际上，编译器想要做的任何事情。至于名称篡改的确切语义，截至本文写作时是未定义的。如果我们打算从 C 调用一个函数，我们必须有确切的符号名称来引用。no_mangle关闭了名称篡改，保留了我们书写的名称。这意味着我们必须小心不要造成符号冲突。类似于导入函数，这里的extern C意味着这个函数应该按照 C ABI 编写。技术上，我们也可以写成extern fn，省略 C，因为 C ABI 是隐式的默认值。

alloc_ckms分配一个新的CKMS，返回对其的可变指针。与 C 的互操作性需要原始指针，这是有道理的。我们在嵌入 Rust 时必须非常注意内存所有权——Rust 拥有内存，这意味着我们需要提供一个释放函数？或者，其他语言拥有内存？大多数情况下，保持 Rust 的所有权更容易，因为为了释放内存，编译器需要知道类型的内存大小。通过传递指针出来，就像我们在这里做的那样，我们让 C 对CKMS的大小一无所知。这个项目的 C 部分只知道它有一个不透明结构体要处理。这是 C 库中常见的策略，有很好的理由。以下是释放CKMS的示例：

#[no_mangle]
pub extern "C" fn free_ckms(ckms: *mut CKMS<f32>) -> () {
    unsafe {
        let ckms = Box::from_raw(ckms);
        drop(ckms);
    }
}

注意，在alloc_ckms中，我们正在装箱CKMS——强制将其放入堆中——而在free_ckms中，我们正在从其指针构建一个装箱的CKMS。我们在第三章“Rust 内存模型——所有权、引用和操作”的上下文中广泛讨论了装箱和释放内存。将值插入CKMS是足够直接的：

#[no_mangle]
pub extern "C" fn ckms_insert(ckms: &mut CKMS<f32>, value: f32) -> () {
    ckms.insert(value)
}

查询需要一点解释：

#[no_mangle]
pub extern "C" fn query(ckms: &mut CKMS<f32>, q: f64, 
                        quant: *mut f32) 
    -> i8 
{
    unsafe {
        if let Some((_, res)) = ckms.query(q) {
            *quant = res;
            0
        } else {
            -1
        }
    }
}

在 C API 中发出错误条件是棘手的。在 Rust 中，我们返回某种复合类型，例如Option。在 C 中，没有为你的 API 构建错误信号结构体就没有这样的事情。除了错误结构体方法之外，通常会在写入答案的指针中写入已知的无意义内容，或者返回一个负值。C 期望将答案写入由 quant 指向的 32 位浮点数中，但没有简单的方法可以将无意义的内容写入数值。因此，查询返回一个i8；成功时为零，失败时为负。更复杂的 API 会通过返回不同的负值来区分失败。

就这些了！当你运行cargo build --release时，一个遵循 C ABI 的静态库将被踢出到target/release目录。我们现在可以将其链接到一个 C 程序中。

C 方面

我们的 C 程序是c_src/main.c。在我们定义embed_quantiles接口之前，我们需要一些系统头文件：

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

唯一稍微不寻常的是time.h。我们引入它是因为我们将随机浮点数推入CKMS结构体。请注意，这不是加密安全的随机数。以下是 C 对刚刚创建的 Rust API 的视图：

struct ckms;

struct ckms* alloc_ckms(double error);
void free_ckms(struct ckms* ckms);
void ckms_insert(struct ckms* ckms, float value);
int8_t query(struct ckms* ckms, double q, float* quant);

注意到CKMS结构体。这是一个不透明的结构体。C 现在知道有一个结构体，但它不知道它有多大。这没关系。我们所有的函数都只对这个结构体的指针进行操作，而 C 知道这个指针的大小。main函数很简单：

int main(void) {
  srand(time(NULL));

  struct ckms* ckms = alloc_ckms(0.001);

  for (int i=1; i <= 1000000; i++) {
    ckms_insert(ckms, (float)rand()/(float)(RAND_MAX/10000));
  }

  float quant = 0.0;
  if (query(ckms, 0.75, &quant) < 0) {
    printf("ERROR IN QUERY");
    return 1;
  }
  printf("75th percentile: %f\n", quant);

  free_ckms(ckms);
  return 0;
}

我们分配一个CKMS，其误差界限为 0.001，将 100 万个随机浮点数加载到CKMS中，然后查询第 75 百分位数，应该大约是 7,500。最后，函数释放CKMS并退出。简短而直接。

现在，使用 clang 编译器构建和链接libembed_quantiles.a相当容易，而使用 GCC 则稍微麻烦一些。我已经包括了一个 Makefile，它已经在 OS X 和 Linux 上进行了测试：

CC ?= $(shell which cc)
CARGO ?= $(shell which cargo)
OS := $(shell uname)

run: clean build
        ./target/release/embed_quantiles

clean:
        $(CARGO) clean
        rm -f ./target/release/embed_quantiles

build:
        $(CARGO) build --release
ifeq ($(OS),Darwin) # Assumption: CC == Clang
        $(CC) -std=c11 -Wall -Werror -Wpedantic -O3 c_src/main.c \
                -L target/release/ -l embed_quantiles \
                -o target/release/embed_quantiles
else # Assumption: CC == GCC
        $(CC) -std=c11 -Wall -Werror -Wpedantic -O3 c_src/main.c \
                -L target/release/ -lpthread -Wl,–no-as-needed -ldl \
                -lm -lembed_quantiles \
                -o target/release/embed_quantiles
endif

.PHONY: clean run

我没有 Windows 机器来测试，所以，嗯，当这不可避免地不起作用时，我真的很抱歉。希望这里的信息足够你快速解决问题。一旦你放好了 Makefile，你应该能够运行 make run 并看到以下类似的内容：

> make run
/home/blt/.cargo/bin/cargo clean
rm -f ./target/release/embed_quantiles
/home/blt/.cargo/bin/cargo build --release
   Compiling quantiles v0.7.1
   Compiling embed_quantiles v0.1.0
    Finished release [optimized] target(s) in 0.91 secs
cc -std=c11 -Wall -Werror -Wpedantic -O3 c_src/main.c \
        -L target/release/ -lpthread -Wl,–no-as-needed -ldl \
        -lm -lembed_quantiles \
        -o target/release/embed_quantiles
./target/release/embed_quantiles
75th percentile: 7499.636230

百分位数将会有所波动，但应该接近 7,500，就像现在这样。

进入 Python

让我们看看如何将 Rust 集成到 Python 中。我们将编写一个函数来计算由 Python 构建的 cytpes 数组中尾随零的数量。由于解释器已经编译并链接，我们无法将 Rust 静态链接到 Python，因此我们需要创建一个动态库。Cargo.toml 项目反映了这一点：

[package]
name = "zero_count"
version = "0.1.0"
authors = ["Brian L. Troutwine <brian@troutwine.us>"]

[dependencies]

[lib]
name = "zero_count"
crate-type = ["dylib"]

唯一的 Rust 文件，src/lib.rs，其中只有一个函数：

#[no_mangle]
pub extern "C" fn tail_zero_count(arr: *const u16, len: usize) -> u64 {
    let mut zeros: u64 = 0;
    unsafe {
        for i in 0..len {
            zeros += (*arr.offset(i as isize)).trailing_zeros() as u64
        }
    }
    zeros
}

tail_zero_count 函数接受一个指向 u16 数组的指针以及该数组的长度。它遍历数组，对每个 u16 调用 trailing_zeros() 并将值累加到全局变量 zeros 中：然后返回这个全局和。在项目的顶部运行 cargo build --release，你将在 target/release 目录下找到项目的动态库——可能是 libzero_count.dylib、libzero_count.dll 或 libzero_count.so，具体取决于你的主机。到目前为止，一切顺利。

现在调用此函数由 Python 负责。以下是一个小型示例，位于项目根目录下的 zero_count.py：

import ctypes
import random

length = 1000000
lzc = ctypes.cdll.LoadLibrary("target/release/libzero_count.dylib")
arr = (ctypes.c_uint16 * length)(*[random.randint(0, 65000) for _ in range(0, length)])
print(lzc.tail_zero_count(ctypes.pointer(arr), length))

我们导入 cytpes 和随机库，然后加载共享库——在这里，遵循 OS X 的命名约定——并将其绑定到 lzc。如果你在除 OS X 以外的操作系统上运行此代码，请编辑此代码以读取 [so|dll]。一旦 lzc 被绑定，我们就使用 ctypes API 创建一个随机的 u16 值数组，并调用该数组上的 tail_zero_count。使用这种方法，Python 被迫在将数组传递给 Rust 之前分配整个数组，所以不要增加太多长度。运行程序只需调用 Python 的 zero_count.py，如下所示：

> python zero_count.py
1000457
>  python zero_count.py
999401
> python zero_count.py
1002295

处理不透明结构指针——就像我们在 C 示例中所做的那样——在 ctypes 文档中有很好的记录。Rust 将不知道区别；它只是输出符合 C ABI 的对象。

进入 Erlang/Elixir

在本章的最后部分，我们将研究将 Rust 集成到 BEAM 中，这是支撑 Erlang 和 Elixir 的虚拟机。BEAM 是一个复杂的工作窃取调度系统，碰巧是可编程的。Erlang 进程是小的 C 结构体，在调度线程之间弹跳，并携带足够的信息，允许对固定数量的指令进行解释。在 Erlang/Elixir 中没有共享内存的概念：系统中的不同并发演员之间的通信必须通过消息传递来实现。这样做有许多好处，并且虚拟机在可能的情况下会做大量工作以避免复制。Erlang/Elixir 进程将消息接收到一个消息队列中，这是一个双端线程安全的队列，我们在整本书中讨论过。

Erlang 和 Elixir 因其高效处理实时高规模 IO 而闻名。毕竟，Erlang 是在爱立信发明的，作为电话控制软件。这些语言不为人所知的是串行性能。Erlang 中的顺序计算相对较慢，只是因为它很容易启动并发计算，这某种程度上弥补了这一点。某种程度上。有时，你需要原始的串行性能。

Erlang 对此有几个解决方案。一个端口通过双向字节流打开一个外部操作系统进程。我们在上一章中看到了一个类似的方法，即 feruscore 嵌入 pmars。一个端口驱动程序是一个链接的共享对象，通常用 C 编写。端口驱动程序接口提供了向 BEAM 的调度器提供中断提示的功能，并且有很多优点。端口驱动程序*是一个进程，必须能够处理 Erlang 进程通常需要处理的事情：服务其消息队列，处理特殊的中断信号，协作地调度自己，等等。这些都是非平凡的编写。最后，Erlang 支持原生实现函数（NIF）的概念。这些比端口驱动程序简单，并且是同步的，它们是简单地可调用的函数，碰巧是用除 Erlang 以外的语言编写的。NIF 是共享库，通常用 C 实现。端口驱动程序和 NIF 都有一个严重的缺点：内存问题会破坏 BEAM 并使你的应用程序离线。Erlang 系统通常部署在容错是一个重要因素的地方，而破坏虚拟机是一个大忌。

因此，Erlang/Elixir 社区对 Rust 有很大的兴趣。Rustler 项目（crates.io/crates/rustler）旨在使将 Rust 结合到 Elixir 项目中作为 NIF 变得简单。让我们看看一个简短的示例项目，由 Sonny Scroggin 在 2018 年旧金山的 Code BEAM 上展示——beamcoin（github.com/blt/beamcoin）。我们将在 SHA 3f510076990588c51e4feb1df990ce54ff921a06处讨论该项目。

beamcoin 项目并未全部列出。我们主要删除了构建配置。你可以在本书的源代码库中找到完整的列表。

Elixir 的构建系统——Rustler 原生目标语言的 BEAM 语言——被称为 Mix。其配置文件位于项目的根目录下的mix.exs：

defmodule Beamcoin.Mixfile do
  use Mix.Project

  def project do
    [app: :beamcoin,
     version: "0.1.0",
     elixir: "~> 1.5",
     start_permanent: Mix.env == :prod,
     compilers: [:rustler] ++ Mix.compilers(),
     deps: deps(),
     rustler_crates: rustler_crates()]
  end

  def application do
    [extra_applications: [:logger]]
  end

  defp deps do
    [{:rustler, github: "hansihe/rustler", sparse: "rustler_mix"}]
  end

  defp rustler_crates do
    [beamcoin: [
      path: "native/beamcoin",
      mode: mode(Mix.env)
    ]]
  end

  defp mode(:prod), do: :release
  defp mode(_), do: :debug
end

这里有很多我们不会涉及的内容。然而，请注意这个部分：

  defp rustler_crates do
    [beamcoin: [
      path: "native/beamcoin",
      mode: mode(Mix.env)
    ]]
  end

在native/beamcoin目录下嵌入的项目中，是我们将要探索的 Rust 库。其 cargo 配置文件位于native/beamcoin/Cargo.toml：

[package]
name = "beamcoin"
version = "0.1.0"
authors = []

[lib]
name = "beamcoin"
path = "src/lib.rs"
crate-type = ["dylib"]

[dependencies]
rustler = { git = "https://github.com/hansihe/rustler", branch = "master" }
rustler_codegen = { git = "https://github.com/hansihe/rustler", branch = "master" }
lazy_static = "0.2"
num_cpus = "1.0"
scoped-pool = "1.0.0"
sha2 = "0.7"

这里没有什么太令人惊讶的。当 Rust 编译这个动态库（libbeamcoin）时，我们已经看到了几乎所有的依赖项。rustler 和 rustler_codegen 分别是 Rustler 的接口和编译器生成器。rustler_codegen 去除了我们可能需要做的很多样板 C 外部工作。sha2 是来自 RustCrypto 项目的 crate，它实现了 sha2 哈希算法。Beamcoin 是一个有点玩笑性质的项目。其想法是在线程之间分配数字，并计算 sha2-256 哈希的后面的零位数，用预设的零位数进行挖掘。在 Erlang 中做这件事会非常慢，但正如我们将看到的，在 Rust 中这是一个相对快速的运算。scoped-pool crate 是一个线程池库，它是可发送的，这意味着它可以放在 lazy_static! 中。

src/lib.rs 的前言足够简单：

#[macro_use]
extern crate lazy_static;
extern crate num_cpus;
extern crate scoped_pool;
extern crate sha2;
#[macro_use]
extern crate rustler;

use rustler::{thread, Encoder, Env, Error, Term};
use scoped_pool::Pool;
use sha2::Digest;
use std::mem;
use std::sync::atomic::{AtomicBool, Ordering};
use std::sync::{mpsc, Arc};

我们之前已经看到了很多这样的内容。Rustler 的导入是 Erlang C NIF API 的类似物。挖掘的难度由一个顶级 usize 控制，称为 DIFFICULTY：

const DIFFICULTY: usize = 6;

这个值控制了在声明可挖掘之前，需要在哈希的后面找到的总零位数。这是我们的线程池：

lazy_static! {
    static ref POOL: Pool = Pool::new(num_cpus::get());
}

我之前提到过，BEAM 维护自己的调度线程。这是真的。beamcoin NIF 也维护了自己的线程池，以分配挖掘任务。现在，Rustler 减少了样板代码，但无法完全去除。例如，我们必须告诉 BEAM 与哪个符号关联的解析函数，并预先定义 原子 以供使用：

rustler_atoms! {
    atom ok;
    atom error;
}

rustler_export_nifs! {
    "Elixir.Beamcoin",
    [("native_mine", 0, mine)],
    None
}

Erlang 原子是一个命名常量。这些是在 Erlang/Elixir 程序中极其常见的数据类型。池中的每个线程都会被分配到一段正整数以供搜索，根据它们的线程号进行剥离。池中的工作者使用 MPSC 通道与挖掘线程通信，告知已找到结果：

#[derive(Debug)]
struct Solution(u64, String);

fn mine<'a>(caller: Env<'a>, _args: &[Term<'a>]) 
    -> Result<Term<'a>, Error> 
{
    thread::spawn::<thread::ThreadSpawner, _>(caller, move |env| {
        let is_solved = Arc::new(AtomicBool::new(false));
        let (sender, receiver) = mpsc::channel();

        for i in 0..num_cpus::get() {
            let sender_n = sender.clone();
            let is_solved = is_solved.clone();

            POOL.spawn(move || {
                search_for_solution(i as u64, num_cpus::get() as u64, 
                                    sender_n, is_solved);
            });
        }

        match receiver.recv() {
            Ok(Solution(i, hash)) => (atoms::ok(), i, hash).encode(env),
            Err(_) => (
                atoms::error(),
                "Worker threads disconnected before the \
                 solution was found".to_owned(),
            ).encode(env),
        }
    });

    Ok(atoms::ok().encode(caller))
}

search_for_solution 函数是一个小循环：

fn search_for_solution(
    mut number: u64,
    step: u64,
    sender: mpsc::Sender<Solution>,
    is_solved: Arc<AtomicBool>,
) -> () {
    let id = number;
    while !is_solved.load(Ordering::Relaxed) {
        if let Some(solution) = verify_number(number) {
            if let Ok(_) = sender.send(solution) {
                is_solved.store(true, Ordering::Relaxed);
                break;
            } else {
                println!("Worker {} has shut down without \
                         finding a solution.", id);
            }
        }
        number += step;
    }
}

在循环的顶部，池中的每个线程都会检查是否有其他线程挖掘了 beamcoin。如果有，函数退出，线程在池中可用于新的工作。否则，调用 verify_number 函数。该函数是：

fn verify_number(number: u64) -> Option<Solution> {
    let number_bytes: [u8; 8] = unsafe { 
        mem::transmute::<u64, [u8; 8]>(number) 
    };
    let hash = sha2::Sha256::digest(&number_bytes);

    let top_idx = hash.len() - 1;
    // Hex chars are 16 bits, we have 8 bits. /2 is conversion.
    let trailing_zero_bytes = DIFFICULTY / 2;

    let mut jackpot = true;
    for i in 0..trailing_zero_bytes {
        jackpot &= hash[top_idx - i] == 0;
    }

    if jackpot {
        Some(Solution(number, format!("{:X}", hash)))
    } else {
        None
    }
}

数字被传递进来，转换成一个包含 8 个成员的字节数组，并进行哈希。如果哈希具有适当数量的尾随零字节，函数结束时 jackpot 为真，并返回数字及其哈希。仔细的读者会注意到，Rust 模块导出了一个名为 native_mine 的 NIF。一般来说，Erlang NIF 有一个系统语言组件，作为后备有一个 BEAM 原生实现。系统语言 NIF 实现传统上被称为 native_*。

最后的部分是包装原生 NIF 位点的 Elixir 模块。这个模块被称为 Beamcoin，位于 lib/beamcoin.ex：

defmodule Beamcoin do
  use Rustler, otp_app: :beamcoin

  require Logger

  def mine do
    :ok = native_mine()

    start = System.system_time(:seconds)
    receive do
      {:ok, number, hash} ->
        done = System.system_time(:seconds)
        total = done - start
        Logger.info("Solution found in #{total} seconds")
        Logger.info("The number is: #{number}")
        Logger.info("The hash is: #{hash}")
      {:error, reason} ->
        Logger.error(inspect reason)
    end
  end

  def native_mine, do: :erlang.nif_error(:nif_not_loaded)
end

安装完 Elixir (elixir-lang.org/install.html) 后，您可以移动到项目的根目录，执行 mix deps.get 以获取项目的依赖项，然后使用 MIX_ENV=prod iex -S mix 来启动 Elixir repl。后者命令看起来可能像这样：

> MIX_ENV=prod iex -S mix
Erlang/OTP 20 [erts-9.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Compiling NIF crate :beamcoin (native/beamcoin)...
    Finished release [optimized] target(s) in 0.70 secs
Interactive Elixir (1.6.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)>

在提示符下，输入 Beamcoin.mine 并按 Enter。几秒钟后，您应该会看到：

iex(1)> Beamcoin.mine

23:30:45.243 [info]  Solution found in 3 seconds

23:30:45.243 [info]  The number is: 10097471

23:30:45.243 [info]  The hash is: 2354BB63E90673A357F53EBC96141D5E95FD26B3058AFAD7B1F7BACC9D000000
:ok

或者，类似的东西。

在 BEAM 中构建 NIFs 是一个复杂的话题，我们在这里几乎没有涉及。Sonny Scroggin 的演讲，包含在 进一步阅读 部分，详细介绍了这个细微差别。如果您对 BEAM 的工作原理感兴趣，我在 进一步阅读 部分也包含了我关于这个主题的演讲。数十年的精心努力都投入到了 BEAM 中，这确实有所体现。

摘要

在本章中，我们讨论了在 Rust 中嵌入语言以及反之亦然。Rust 是一种非常有用的编程语言，它本身就是一个强大的工具，但经过精心设计，可以与现有的语言生态系统互操作。将困难的并发工作委托给 Rust 在一个内存不安全的环境中是一个强大的模型。Mozilla 在 Firefox 上的工作已经证明了这条道路是富有成效的。同样，有数十年的经过良好测试的库和特定领域——天气建模、物理学、20 世纪 80 年代的有趣编程游戏——理论上可以用 Rust 重新编写，但可能更好地通过安全接口来整合。

本章是最后一章，旨在教会您一项新的、广泛的技能。如果您已经读到这本书的这一部分，感谢您。为您写作是一段真正的乐趣。希望您现在对在 Rust 中进行底层并发有了坚实的基础，并且有信心阅读您遇到的绝大多数 Rust 代码库。Rust 中有很多内容，希望现在看起来更熟悉了。在本书的下一章，也是最后一章中，我们将讨论 Rust 的未来，哪些语言特性与本书相关即将到来，以及它们如何为我们带来新的能力。

进一步阅读

• Rust 编写的 FFI 示例，可在 github.com/alexcrichton/rust-ffi-examples 找到。Alex Crichton 的这个仓库是一个 Rust 中 FFI 示例的良好集合。这本书中关于这个主题的文档相当不错，但仔细阅读工作代码总不会有害。

• 《黑客的乐趣》，亨利·沃伦（小）。如果您喜欢本章对 feruscore 的处理中包含的位操作，您会喜欢《黑客的乐趣》。这本书现在已经过时了，其中一些算法在 64 位字上不再工作，但它仍然值得一读，尤其是如果您像我一样，努力将固定宽度类型保持得尽可能小。

• 外部函数接口，可在doc.rust-lang.org/nomicon/ffi.html找到。Nomicon 为压缩库 snappy 构建了一个高级包装器。这个包装器在以下方面进行了扩展，具体来说是与 C 回调和 vardic 函数调用相关。

• 全局解释器锁，可在wiki.python.org/moin/GlobalInterpreterLock找到。GIL 长期以来一直是用 Python 编写的多进程软件的痛处。这篇维基百科条目讨论了强制执行 GIL 的技术细节以及历史上试图解决这个问题所做的尝试。

• Rust 之旅，可在github.com/chucklefish/rlua/blob/master/examples/guided_tour.rs找到。rlua crate 包含一个导游模块，该模块有很好的文档和可运行性。我在其他项目中没有看到过这种文档方法，我强烈建议你检查一下。首先，它对学习 rlua 很有帮助。其次，它写得很好，对读者有同情心：这是技术写作的一个很好的例子。

• 链接，可在doc.rust-lang.org/reference/linkage.html找到。这是 Rust 参考手册中的链接章节。这里的细节非常具体，但在明确链接时通常有必要。普通读者可能会或多或少地使用我们在这章中涵盖的信息，但总有一些新的领域需要特定的知识。

• Rust 在其他语言中，可在doc.rust-lang.org/1.2.0/book/rust-inside-other-languages.html找到。这本书的这一章与本章类似——嵌入 Rust，但速度更快，并且使用了不同的高级语言。具体来说，本书涵盖了将 Rust 嵌入 Ruby 和 NodeJS，而我们没有涉及。

• Rust 中的 FFI - 为 libcpuid 编写绑定，可在siciarz.net/ffi-rust-writing-bindings-libcpuid/找到。Zbigniew Siciarz 已经撰写了关于 Rust 的文章，并用 Rust 进行写作有一段时间了。你可能知道他的 24 天 Rust 系列。在这篇文章中，Sicarz 记录了为 libcpuid 构建安全包装器的过程，该库的职责是轮询操作系统以获取有关用户 CPU 的信息。

• 用 Rust 将 Elixir 带到金属上，Sonny Scroggin，可在www.youtube.com/watch?v=lSLTwWqTbKQ找到。在这一章中，我们展示了 Beamcoin，这是在同一项目中结合了 Elixir 和 Rust。将 NIFs 集成到 BEAM 系统是一个复杂的话题。这个在 2017 年 NDC London 上发表的演讲强烈推荐作为该主题的介绍。

• 零散拼凑至太空：可靠性、安全性与 Erlang 原则，作者：Brian L. Troutwine，可在www.youtube.com/watch?v=pwoaJvrJE_U找到。几十年来，在 BEAM 上投入了大量的工作，使得这些语言在容错软件部署中占据了关键位置。没有检查的情况下，BEAM 是如何工作的，这本身就是一个谜。在这场演讲中，我介绍了 BEAM 的语义模型，然后从高层次上讨论了它的实现。

第十章：未来主义——近期的 Rust

本书我们已经涵盖了大量的内容。

如果你已经从另一种系统编程语言中很好地了解了并行编程，我希望你现在对 Rust 的操作方式有了自信的掌握。它的所有权模型是严格的，一开始可能会感觉陌生。如果我的个人经验可以作为一个普遍的指南，那么不安全的 Rust 感觉更熟悉。我希望你也开始欣赏 Rust 的一般安全性，以及它在需要时在内存中执行繁琐操作的能力。我发现能够实现不安全代码，然后将其封装在安全接口中，这对我来说是不可思议的。

如果你已经从高级、垃圾回收的编程语言中相当熟悉并行编程，那么我希望这本书已经作为系统级并行编程的入门为你提供了帮助。正如你所知，内存安全并不能保证正确运行，因此这本书持续关注测试——生成性和模糊测试，以及性能检查——并对模型进行仔细推理。我主张，Rust 由于语言对所有权管理和生命周期的关注以及强大的静态类型系统，是易于进行良好并行编程的系统语言之一。Rust 并非对错误免疫——事实上，它容易受到广泛的错误影响——但这些在现代硬件上的所有语言都是共通的，而且 Rust 确实设法解决了一系列与内存相关的问题。

如果你已经了解 Rust，但不太了解并行编程，我非常希望这本书已经设法让你相信了一件事——并发不是魔法。并行编程是一个广泛的领域，需要大量的研究，但它可以理解和掌握。此外，它不必一次性掌握。这本书的形状为多条路径中的一条提供了论据。希望这本书能成为你旅程中的第一本书。

无论你的背景如何，感谢你阅读到最后一页。我知道，有时覆盖的材料并不容易，完成这一切肯定需要真正的意志力。我非常感激。我写这本书是为了满足我十年前的愿望。有机会把它写出来给你看，这是一件真正令人愉快的事情。

到本章结束时，我们将：

• 讨论了 Rust 中 SIMD 的未来

• 讨论了 Rust 中异步 I/O 的未来

• 讨论了专业化的稳定性和其可能的形式

• 讨论了 Rust 的更广泛的测试方法

• 介绍了参与 Rust 社区的各种途径

技术要求

本章没有软件要求。

你可以在 github.com/PacktPublishing/Hands-On-Concurrency-with-Rust 找到这本书项目的源代码。第十章的源代码位于 Chapter10/。

近期改进

2018 年 Rust 开发的重点是稳定化。自 2015 年的 1.0 版本以来，许多重要的 crate 仅限于夜间使用，无论是由于编译器的修改还是因为担心过于快速地标准化令人尴尬的 API。这种担忧是合理的。当时，Rust 是一种新的语言，它在 1.0 版本前的变化非常剧烈。一种新的语言需要时间来形成其自然风格。到 2017 年底，社区普遍认为需要一个稳定周期，即语言的某些自然表达已经或多或少地确立，而在这些方面没有确立的地方，通过一些工作可以确立。

让我们讨论一下与书中所讨论的主题相关的这个稳定化工作。

SIMD

在这本书中，我们讨论了基于线程的并发。在第八章高级并行性 – Threadpools, Parallel Iterators, and Processes 中，我们通过 Rayon 的并行迭代器达到了更高的抽象层次。正如我们所看到的，rayon 使用了一个复杂的工作窃取线程池。线程只是现代 CPU 上实现并发的一种方法。从某种意义上说，具有深度预取流水线和复杂的分支预测器的 CPU 上的串行程序是并行的，正如我们在第二章顺序 Rust 性能和测试中看到的。利用这种并行性是一个精心设计数据结构并管理对其访问的问题，以及其他我们讨论的细节。在这本书中，我们没有探讨如何利用现代 CPU 并行执行连续内存中相同操作的能力，而不需要求助于线程——向量化。我们没有探讨这一点，因为在我写这篇文章的时候，该语言的标准库中只为向量化指令提供了最小限度的支持。

向量化有两种变体——MIMD 和 SIMD。MIMD 代表多个指令，多个数据。SIMD 代表单指令，单数据。基本思路是这样的：现代 CPU 可以并行地将一条指令应用于连续的、特定大小的数据块。仅此而已。现在，考虑一下在这本书中我们编写了多少个循环，其中我们对循环的每个元素都执行了完全相同的操作。不止几个！如果我们调查了字符串算法或者考虑进行数值计算——加密、物理模拟等——那么在这本书中就会有更多这样的循环。

当我写下这些文字时，SIMD 向量化合并到标准库的进程被 RFC 2366（github.com/rust-lang/rfcs/pull/2366）所阻碍，目标是到年底前将 x86 SIMD 纳入稳定渠道，其他架构随后跟进。读者可能还记得第一章，“预备知识——机器架构和 Rust 入门”，其中提到 x86 和 ARM 的内存系统相当不同。嗯，这种差异也扩展到了它们的 SIMD 系统。确实可以通过稳定的 Rust 通过 stdsimd（crates.io/crates/stdsimd）和 simd（crates.io/crates/simd）crate 来利用 SIMD 指令。对于程序员来说，stdsimd crate 是最好的目标，因为它最终将成为标准库的实现。

由于剩余空间有限，关于 SIMD 的讨论超出了本书的范围。简单来说，正确处理 SIMD 的细节与正确处理原子编程的细节难度相当。我预计，在稳定化之后，社区将构建高级库来利用 SIMD 方法，而无需进行大量的预先学习，尽管可能优化空间较小。例如，faster（crates.io/crates/faster）crate 以 rayon 的精神暴露了 SIMD 并行迭代器。从最终用户的角度来看，那里的编程模型极其方便。

十六进制编码

让我们看看 stdsimd crate 的一个例子。我们在这里不会深入挖掘；我们只是想对这种编程的结构有一个大致的了解。我们已经拉取了 stdsimd 在2f86c75a2479cf051b92fc98273daaf7f151e7a1。我们将要检查的文件是examples/hex.rs。程序的目的是对 stdin 进行hex编码。例如：

> echo hope | cargo +nightly run --release --example hex -p stdsimd
    Finished release [optimized + debuginfo] target(s) in 0.52s
     Running `target/release/examples/hex`
686f70650a

注意，这需要 nightly 渠道，而不是我们在这本书中迄今为止所使用的稳定渠道。我在 nightly，2018-05-10 上进行了测试。实现细节变化非常快，依赖于如此不稳定的编译器特性，因此您应该确保使用列出的特定 nightly 渠道，否则示例代码可能无法编译。

examples/hex.rs的序言部分包含了许多我们在这本书中尚未见过的信息。让我们分两块来看，并揭示未知的内容：

#![feature(stdsimd)]
#![cfg_attr(test, feature(test))]
#![cfg_attr(feature = "cargo-clippy",
            allow(result_unwrap_used, print_stdout, option_unwrap_used,
                  shadow_reuse, cast_possible_wrap, cast_sign_loss,
                  missing_docs_in_private_items))]

#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
#[macro_use]
extern crate stdsimd;

#[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))]
extern crate stdsimd;

因为我们坚持使用稳定的 Rust，所以我们之前没有见过 #![feature(stdsimd)] 这样的东西。这是什么？Rust 允许有冒险精神的用户启用 rustc 中存在但尚未在语言的夜间版本中公开的功能。我说冒险是因为一个正在进行中的功能可能在其开发过程中保持稳定的 API，或者它可能每隔几天就改变一次，需要消费者端的更新。那么，cfg_attr 是什么？这是一个条件编译属性，可以选择性启用功能。你可以在 The Rust Reference 中了解所有关于它的信息，该信息链接在 进一步阅读 部分。有很多细节，但想法很简单——根据用户指令（如测试或运行环境）打开或关闭代码片段。

这后面的内容是 #[cfg(any(target_arch = "x86", target_arch = "x86_64"))] 的意思。在 x86 或 x86_64 上，stdsimd 将通过宏启用并外置，在其他平台上则不启用。现在，希望下面的前言部分是自解释的：

#[cfg(test)]
#[macro_use]
extern crate quickcheck;

use std::io::{self, Read};
use std::str;

#[cfg(target_arch = "x86")]
use stdsimd::arch::x86::*;
#[cfg(target_arch = "x86_64")]
use stdsimd::arch::x86_64::*;

这个程序的 main 函数相当简短：

fn main() {
    let mut input = Vec::new();
    io::stdin().read_to_end(&mut input).unwrap();
    let mut dst = vec![0; 2 * input.len()];
    let s = hex_encode(&input, &mut dst).unwrap();
    println!("{}", s);
}

整个 stdin 被读入输入，并创建了一个简短的向量来存储哈希值，称为 dst。还使用了 hex_encode。第一部分执行输入验证：

fn hex_encode<'a>(src: &[u8], dst: &'a mut [u8]) -> Result<&'a str, usize> {
    let len = src.len().checked_mul(2).unwrap();
    if dst.len() < len {
        return Err(len);
    }

注意返回值——成功时返回 &str，失败时返回 usize——错误的长度。函数的其余部分稍微复杂一些：

    #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
    {
        if is_x86_feature_detected!("avx2") {
            return unsafe { hex_encode_avx2(src, dst) };
        }
        if is_x86_feature_detected!("sse4.1") {
            return unsafe { hex_encode_sse41(src, dst) };
        }
    }

    hex_encode_fallback(src, dst)
}

这引入了条件编译，我们之前已经见过，还包含了一个新内容——is_x86_feature_detected!。这个宏是 SIMD 功能的新特性，它在运行时通过 libcpuid 测试给定的 CPU 功能是否可用。如果是，则使用该功能。例如，在 ARM 处理器上，将执行 hex_encode_fallback。在 x86 处理器上，将根据芯片的确切能力执行 avx2 或 sse4.1 之一的实现。哪个实现被调用是在运行时确定的。让我们首先看看 hex_encode_fallback 的实现：

fn hex_encode_fallback<'a>(
    src: &[u8], dst: &'a mut [u8]
) -> Result<&'a str, usize> {
    fn hex(byte: u8) -> u8 {
        static TABLE: &[u8] = b"0123456789abcdef";
        TABLE[byte as usize]
    }

    for (byte, slots) in src.iter().zip(dst.chunks_mut(2)) {
        slots[0] = hex((*byte >> 4) & 0xf);
        slots[1] = hex(*byte & 0xf);
    }

    unsafe { Ok(str::from_utf8_unchecked(&dst[..src.len() * 2])) }
}

内部函数 hex 作为一个静态查找表，for 循环将 src 中的字节和从 dst 中拉取的两个块组合在一起，在循环过程中更新 dst。最后，dst 被转换为 &str 并返回。在这里使用 from_utf8_unchecked 是安全的，因为我们能验证 dst 中不可能存在非 utf8 字符，从而节省了检查。

好吧，现在这是后备方案。SIMD 变体是如何读取的？我们将查看 hex_encode_avx2，将 sse4.1 变体留给有抱负的读者。首先，我们看到条件编译和熟悉的功能类型再次出现：

#[target_feature(enable = "avx2")]
#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
unsafe fn hex_encode_avx2<'a>(
    mut src: &[u8], dst: &'a mut [u8]
) -> Result<&'a str, usize> {

到目前为止，一切顺利。现在，看看以下内容：

    let ascii_zero = _mm256_set1_epi8(b'0' as i8);
    let nines = _mm256_set1_epi8(9);
    let ascii_a = _mm256_set1_epi8((b'a' - 9 - 1) as i8);
    let and4bits = _mm256_set1_epi8(0xf);

好吧，函数 _mm256_set1_epi8 确实是新的！文档（rust-lang-nursery.github.io/stdsimd/x86_64/stdsimd/arch/x86_64/fn._mm256_set1_epi8.html）中说明了以下内容：

"将 8 位整数 a 广播到返回向量的所有元素。"

好的。哪个向量？许多 SIMD 指令都是以隐式大小的向量的形式执行的，大小由 CPU 架构定义。例如，我们一直在查看的函数返回一个 stdsimd::arch::x86_64::__m256i，一个 256 位宽的向量。所以，ascii_zero 是 256 位的零，ascii_a 是 256 位的 a，以此类推。顺便说一句，这些函数和类型都遵循英特尔命名方案。我理解 LLVM 使用自己的命名方案，但 Rust 为了减少开发者混淆，维护了一个从架构名称到 LLVM 名称的映射。通过保留架构名称，Rust 使得查找每个内嵌函数的详细信息变得非常容易。您可以在 mm256_set1_epi8 的 英特尔内嵌函数指南 中看到这一点（software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm256_set1_epi8&expand=4676)。

实现然后进入一个循环，以 256 位宽的块处理 src，直到只剩下 32 位或更少：

    let mut i = 0_isize;
    while src.len() >= 32 {
        let invec = _mm256_loadu_si256(src.as_ptr() as *const _);

变量 invec 现在是 src 的 256 位，_mm256_loadu_si256 负责执行加载。SIMD 指令必须在其原生类型上操作，您明白的。在机器的实际现实中，没有类型，但有专用寄存器。接下来要讨论的内容很复杂，但我们可以通过推理来理解：

        let masked1 = _mm256_and_si256(invec, and4bits);
        let masked2 = _mm256_and_si256(
            _mm256_srli_epi64(invec, 4),
            and4bits
        );

好的，_mm256_and_si256 执行两个 __m256i 的按位布尔与操作，返回结果。masked1 是 invec 和 and4bits 的按位布尔与操作。对于 masked2 也是如此，但我们需要确定 _mm256_srli_epi64 做了什么。英特尔文档中说明了以下内容：

"将打包的 64 位整数在 dst 中右移 imm8 位，同时移入零，并将结果存储在 dst 中。"

invec 被细分为四个 64 位整数，然后这些整数右移四位。然后与 and4bits 进行布尔与操作，masked2 就出现了。如果您回顾 hex_encode_fallback 并稍微眯一下眼睛，您就可以开始看到它与 (*byte >> 4) & 0xf 的关系。接下来，两个比较掩码被组合在一起：

        let cmpmask1 = _mm256_cmpgt_epi8(masked1, nines);
        let cmpmask2 = _mm256_cmpgt_epi8(masked2, nines);

_mm256_cmpgt_epi8 对 256 位向量中的 8 位块进行大于比较，返回较大的字节。然后使用比较掩码来控制 ascii_zero 和 ascii_a 的混合，并将该结果添加到 masked1：

        let masked1 = _mm256_add_epi8(
            masked1,
            _mm256_blendv_epi8(ascii_zero, ascii_a, cmpmask1),
        );
        let masked2 = _mm256_add_epi8(
            masked2,
            _mm256_blendv_epi8(ascii_zero, ascii_a, cmpmask2),
        );

混合是按字节进行的，每个字节的最高位决定是否将字节从 arg 列表中的第一个向量或第二个向量移动过来。然后计算出的掩码交错选择高半部和低半部：

        let res1 = _mm256_unpacklo_epi8(masked2, masked1);
        let res2 = _mm256_unpackhi_epi8(masked2, masked1);

在交错掩码的高半部分，目标地址的前 128 位被填充自源地址的最高 128 位，其余位用零填充。在交错掩码的低半部分，目标地址的前 128 位被填充自源地址的最低 128 位，其余位用零填充。最后，计算出一个指向dst的指针，以 64 位步长进行计算，并进一步细分为 16 位块，然后在这里存储res1和res2：

        let base = dst.as_mut_ptr().offset(i * 2);
        let base1 = base.offset(0) as *mut _;
        let base2 = base.offset(16) as *mut _;
        let base3 = base.offset(32) as *mut _;
        let base4 = base.offset(48) as *mut _;
        _mm256_storeu2_m128i(base3, base1, res1);
        _mm256_storeu2_m128i(base4, base2, res2);
        src = &src[32..];
        i += 32;
    }

当src小于 32 字节时，会对其调用hex_encode_sse4，但我们将细节留给有冒险精神的读者：

    let i = i as usize;
    let _ = hex_encode_sse41(src, &mut dst[i * 2..]);

    Ok(str::from_utf8_unchecked(
        &dst[..src.len() * 2 + i * 2],
    ))
}

这很困难！如果我们在这里的目标不仅仅是了解 SIMD 编程风格，那么我们可能需要手动分析这些指令在位级别上的工作方式。这值得吗？这个例子来自 RFC 2325 (github.com/rust-lang/rfcs/blob/master/text/2325-stable-simd.md)，稳定的 SIMD。他们的基准测试表明，我们最初查看的回退实现每秒大约可以散列 600 兆字节。avx2 实现每秒散列 15,000 MB，性能提升了 60%。这并不算差。而且要记住，每个 CPU 核心都配备了 SIMD 能力。你还可以将这些计算分配给线程。

就像原子编程一样，SIMD 既不是万能的，也不是特别容易。不过，如果你需要速度，那么这些努力是值得的。

Futures 和 async/await

异步 I/O 现在是 Rust 生态系统中的热门话题。我们在第八章“高级并行性 – 线程池、并行迭代器和进程”中简要讨论的 C10K 挑战，在操作系统引入可伸缩的 I/O 通知系统调用（如 BSD 中的 kqueue 和 Linux 中的 epoll）时得到了解决。在 epoll、kqueue 及其朋友出现之前，I/O 通知的处理时间随着文件描述符数量的增加而呈线性增长——这是一个真正的问题。本书中我们采取的积极而天真的网络方法也遭受了线性增长。我们为监听而打开的每个 TCP 套接字都需要在循环中进行轮询，这导致高流量连接得不到充分服务，而其他连接则得到了过多的服务。

Rust 的可扩展网络 I/O 抽象是 mio (crates.io/crates/mio)。如果你在 mio 内部探索，你会发现它是一些常见平台（Windows、Unixen）的 I/O 通知子系统的干净适配器：这就是全部了。mio 的用户不会得到很多额外的支持。你的 mio 套接字存储在哪里？这取决于程序员。你能包含多线程吗？由你决定。现在，这对非常具体的用例来说很棒——例如，cernan 使用 mio 来驱动其入口 I/O，因为我们希望对这些细节有非常精细的控制——但除非你有非常具体的需求，否则这可能会对你来说是一个非常繁琐的情况。社区已经在 tokio (crates.io/crates/tokio)上投入了大量的精力，这是一个用于执行可扩展 I/O 的框架，它具有如背压、事务取消和高级抽象等基本功能，以简化请求/响应协议。Tokio 是一个快速发展的项目，但几乎肯定将成为未来几年中的关键项目之一。Tokio 在本质上是一个基于反应器（en.wikipedia.org/wiki/Reactor_pattern）的架构；一个 I/O 事件变得可用，然后调用你已注册的处理程序。

如果你只需要响应一个事件，基于反应器的系统编程足够简单。但是，比你想象的更常见的是，在真实系统中，I/O 事件之间存在依赖关系——一个进入的 UDP 数据包会导致对网络内存缓存的 TCP 往返，这又导致对原始进入系统的出口 UDP 数据包，以及另一个。协调这一点是困难的。Tokio——以及 Rust 生态系统在某种程度上——完全投入了一个名为 futures (crates.io/crates/futures)的承诺库。承诺是对异步 I/O 的一个相当整洁的解决方案：底层的反应器调用一个已建立的接口，你在其中实现一个闭包（或一个特质，然后将其放入该接口），这样每个人的代码都保持松散耦合。Rust 的 futures 是可轮询的，这意味着你可以在一个 future 上调用 poll 函数，它可能解析为一个值或一个通知，表明该值尚未准备好。

这与其他语言的承诺系统类似。但是，正如任何记得 NodeJS 早期引入 JavaScript 生态系统的人都可以证明的那样，没有语言支持的承诺会变得很奇怪，并且很快就会变得非常嵌套。Rust 的借用检查器使得情况变得更糟，需要装箱或完全的弧，而在直线代码中，这本来是不必要的。

将承诺作为一等关注点的语言通常会演变 async/await 语法。异步函数是 Rust 中返回未来而几乎没有其他内容的函数。Rust 的未来是一个简单的特质，它从 futures 项目中提取出来。实际的实现将存在于语言的标准库之外，并允许有替代实现。异步函数的内部不会立即执行，而只有在未来被轮询时才会执行。函数的内部通过轮询执行，直到遇到 await 点，导致一个通知，表明值尚未准备好，并且正在轮询未来的任何内容都应该继续进行。

正如其他语言一样，Rust 提出的 async/await 语法实际上是在显式回调链结构之上的糖衣。但是，由于 async/await 语法和 futures 特质正在进入编译器，可以向借用检查系统添加规则以消除当前的装箱关注点。我预计，一旦它们变得更容易交互，你将看到更多稳定版 Rust 中的 futures。确实，正如我们在第八章《高级并行性——池、迭代器和进程》中看到的那样，rayon 正在投资时间开发基于 futures 的接口。

特定化

在第二章《顺序 Rust 性能和测试》中，我们提到，如果数据结构实现者打算针对稳定版 Rust 进行目标开发，特定化技术将被切断。特定化是一种方法，通过这种方法，一个泛型结构——比如一个HashMap——可以针对一个特定类型进行具体实现。通常，这样做是为了提高性能——比如将具有u8键的HashMap转换为数组——或者在可能的情况下提供一个更简单的实现。特定化在 Rust 中已经存在了一段时间，但由于与生命周期交互时的稳定性问题，它仅限于夜间项目，如编译器。经典的例子一直是以下内容：

trait Bad1 {
    fn bad1(&self);
}

impl<T> Bad1 for T {
    default fn bad1(&self) {
        println!("generic");
    }
}

// Specialization cannot work: trans doesn't know if T: 'static
impl<T: 'static> Bad1 for T {
    fn bad1(&self) {
        println!("specialized");
    }
}

fn main() {
    "test".bad1()
}

生命周期在编译过程中的某个点被消除。字符串字面量是静态的，但在调用特定类型之前，编译器中信息不足，无法做出决定。在特定化中的生命周期等价性也带来了困难。

有很长一段时间，人们认为特定化将错过 2018 年语言中包含的机会。现在，也许将包含一种更有限的特定化形式。只有当实现是关于生命周期的泛型时，特定化才会适用，它不会在特质生命周期中引入重复，不会重复泛型类型参数，并且所有特质界限本身都适用于特定化。具体的细节在我写这篇文章时还在变化，但请务必留意。

有趣的项目

目前 Rust 社区中有很多有趣的项目。在本节中，我想探讨两个我在书中没有详细讨论的项目。

模糊测试

在前面的章节中，我们使用 AFL 来验证我们的程序没有出现崩溃行为。虽然 AFL 非常常用，但它并不是 Rust 可用的唯一 fuzzer。LLVM 有一个本地的库——libfuzzer (llvm.org/docs/LibFuzzer.html)——覆盖了相同的空间，而 cargo-fuzz (crates.io/crates/cargo-fuzz)项目则充当执行器。你可能也对 honggfuzz-rs (crates.io/crates/honggfuzz)感兴趣，这是一个由 Google 开发的 fuzzer，用于搜索与安全相关的违规行为。它是原生多线程的——无需手动启动多个进程——并且可以进行网络 fuzzing。我传统上更喜欢使用 AFL 进行 fuzzing。honggfuzz 项目势头强劲，读者应该在他们的项目中尝试一下。

Seer，Rust 的符号执行引擎

如我们之前讨论的，fuzzing 通过随机输入和二进制仪器探索程序的状态空间。这可能会很慢。符号执行 (en.wikipedia.org/wiki/Symbolic_execution) 的雄心是允许对状态空间进行相同的探索，但无需随机探测。搜索程序崩溃是应用的一个领域，但它也可以与证明工具一起使用。在精心编写的程序中，符号执行可以让你证明你的程序永远不会达到错误状态。Rust 有一个部分实现的符号执行工具 seer (github.com/dwrensha/seer)。该项目使用 z3，一个约束求解器，在程序分支处生成分支输入。Seer 的 README，截至 SHA 91f12b2291fa52431f4ac73f28d3b18a0a56ff32，有趣地解码了一个哈希值。这是通过定义哈希数据的解码为可崩溃条件来完成的。Seer 运行了一段时间后解码了哈希值，导致程序崩溃。它将解码的值报告在错误报告中。

对于 seer 来说，现在还处于早期阶段，但潜力是存在的。

社区

Rust 社区庞大且多元化。实际上，它如此之大，以至于很难知道在有问题或想法时该去哪里。更重要的是，中级到高级水平的书籍通常会假设读者对语言社区的了解与作者一样多。虽然我一直处于作者和读者关系的另一边，但我一直觉得这种假设令人沮丧。然而，作为一个作者，我现在理解了这种犹豫——社区信息不会保持更新。

唉，有些信息在你看到的时候可能已经过时了。读者请注意。

在整本书中，我们提到了 crates 生态系统；crates.io（[crates.io/](https://crates.io/））是 Rust 源项目的唯一位置。docs.rs（[https://docs.rs/](https://docs.rs/））是理解 crates 的重要资源，由 Rust 团队运营。您还可以使用cargo docs来获取您项目依赖文档的本地副本。我经常没有 Wi-Fi，我发现这非常有用。

与 Rust 中的几乎所有事物一样，社区本身在这网页上有文档（https://www.rust-lang.org/en-US/community.html）。IRC 对于实时、松散的对话来说相当常见，但 Rust 的沟通确实侧重于面向网络的方面。用户论坛（[users.rust-lang.org/](https://users.rust-lang.org/））是一个面向使用该语言并有问题或公告的人的网页论坛。编译器人员以及标准库实现者等都在内部论坛（[https://internals.rust-lang.org/](https://internals.rust-lang.org/））上闲逛。正如您可能预期的那样，这两个社区有很大的重叠。

在整本书中，我们引用了各种 RFC。Rust 通过一个请求评论系统进行演变，所有这些都被集中管理（https://github.com/rust-lang/rfcs）。这仅针对 Rust 编译器和标准库。许多社区项目遵循类似的系统——例如，crossbeam RFCs（github.com/crossbeam-rs/rfcs）。顺便说一句，这些值得阅读。

我应该使用unsafe吗？

听到以下观点的变体并不罕见——我不会使用任何包含unsafe块的库。这种观点背后的理由是unsafe，嗯，表明该库可能存在潜在的不安全性，并可能导致您精心设计的程序崩溃。这是真的——某种程度上。正如我们在本书中看到的，使用unsafe构建一个在运行时完全安全的项目的可能性是存在的。我们也看到，不使用unsafe块构建的项目在运行时也可能失败。unsafe块的存在与否不应减少原始程序员对尽职调查的责任——编写测试、使用模糊测试工具探测实现等。此外，unsafe块的存在与否也不免除 crates 用户承担同样的责任。任何软件，在某种程度上，如果没有被证明是安全的，都应该被视为可疑。

勇敢地使用unsafe关键字。在必要时这样做。记住，编译器将无法像通常那样为您提供帮助——仅此而已。

摘要

在本书的最后一章中，我们讨论了即将到来的 Rust 语言的近中期改进——在野外一段时间后稳定的功能，大型项目的基础集成，可能或可能不成功的研发，以及其他主题。其中一些主题在本书的第二版中肯定会有自己的章节，如果本书有新版本的话（告诉你的朋友去买一本吧！）。我们还谈到了社区，这是寻找持续讨论、提问和参与的地方。然后，我们确认了，是的，当你有理由这样做时，你应该在 unsafe Rust 中编写代码。

好了，这就结束了。这本书的内容到此结束。

进一步阅读

• 交付专长：一个关于稳健性的故事，可在 aturon.github.io/blog/2017/07/08/lifetime-dispatch/ 查阅。长期以来，人们一直渴望看到专长在稳定版 Rust 中可用，而且并非没有尝试过，但至今仍未实现。在这篇博客文章中，Aaron Turon 讨论了 2017 年专长的困难，并在讨论中介绍了 Chalk 逻辑解释器。Chalk 本身就很有趣，尤其是如果你对编译器内部或逻辑编程感兴趣。

• 最大最小化专长：始终适用的 impl，可在 smallcultfollowing.com/babysteps/blog/2018/02/09/maximally-minimal-specialization-always-applicable-impls/ 查阅。Niko Matsakis 在这篇文章中扩展了 Turon 的 交付专长 文章中讨论的主题，讨论了专长稳健性的最小-最大解决方案。这种方法似乎是最有可能最终实现的方法，但发现了缺陷。幸运的是，这些缺陷是可以解决的。这篇帖子是 Rust 社区中预 RFC 对话的一个很好的例子。

• 针对 Rust 的声音和人体工程学专长，可在 aturon.github.io/2018/04/05/sound-specialization/ 查阅。这篇博客文章讨论了最小-最大文章中的问题，并提出了本章讨论的实现方案。截至撰写本书时，这可能是最有可能实现的方法，除非有人发现了其中的缺陷。

• Chalk，可在 github.com/rust-lang-nursery/chalk 查阅。Chalk 真的是一个非常有意思的 Rust 项目。根据项目描述，它是一个用 Rust 编写的 PROLOG 风格的解释器。到目前为止，Chalk 正被用来在 Rust 语言中推理专长，但计划有一天将其合并到 rustc 本身。截至 SHA 94a1941a021842a5fcb35cd043145c8faae59f08 的项目 README 中列出了关于 chalk 应用的优秀文章。

• 《不稳定的书籍》，可在doc.rust-lang.org/nightly/unstable-book/找到。rustc拥有大量正在开发中的特性。《不稳定的书籍》旨在收集这些特性、它们背后的理由以及任何相关的跟踪问题，值得一读，尤其是如果你打算为编译器项目做出贡献的话。

• Rust 中的零成本 future，可在aturon.github.io/blog/2016/08/11/futures/找到。这篇文章向 Rust 社区介绍了 future 项目，并很好地解释了引入它的动机。随着时间的推移，future 的实际实现细节已经发生了变化，但这篇文章仍然值得一读。

• 异步/等待，可在github.com/rust-lang/rfcs/blob/master/text/2394-async_await.md找到。RFC 2394 介绍了简化 Rust 中 future 的易用性的动机，并概述了其实施方法。该 RFC 本身是 Rust 如何演化的一个很好的例子——社区的需求转化为实验，然后转化为编译器的支持。