Updated 'src/Ch16_Fearless_Concurrency'.

src/Ch16_Fearless_Concurrency.md

@@ -1,23 +1,20 @@
 # 无惧并发
 
-**Fearless Concurrency**
+安全并高效地处理并发编程，是 Rust 的另一主要目标。所谓 *并发编程，concurrent programming*，是指程序的各部分独立地执行，而 *并行编程，parallel programming*，是指程序的不同部分同时执行，随着越来越多的计算机利用其多个处理器，这两种编程范式变得日益重要。历史上，这两种情景下的编程一直都是既困难又容易出错。Rust 有望改变这一点。
 
-安全并高效地处理并发编程，是 Rust 的另一主要目标。所谓 *并发编程，concurrent programming*，是指其中程序的各部分独立地执行着，而 *并行编程，parallel programming*，则是指程序的不同部分于同一时间执行，随着越来越多的计算机利用了多处理器的优势，这两种编程范式变得日益重要起来。历史上，这两种情景下的编程，曾是有难度且容易出错的：Rust 就有望来改变这种局面。
+> **译注**：【Erlang/OTP](https://erl.xfoss.com) 属于一门专注于并发编程的语言，其甚至提出 “concurrency-oriented programming” 模型。
 
-早期阶段，Rust 团队曾认为确保内存安全与防止并发问题，属于要以不同方法来解决的两个单独挑战。随着时间的推移，团队发现所有权与类型系统，正是有助于管理内存安全，*及* 并发问题的一套强有力的工具！经由利用所有权与类型检查，许多的并发错误，就成了 Rust 中的编译时错误，而非运行时错误。因此，就不再是要咱们，在出现运行时并发错误时，花费大量时间尽力重现那些确切情形，而是那些不正确代码，将拒绝编译，并给出代码问题的错误提示。由此，咱们就可以在编写出错误代码时，而非潜在地于交付代码到生产之后，修复好这些代码。这里将 Rust 此方面的特性，亲切地取名为 *无惧并发，fearless concurrency*。无惧并发实现了编写出不带难以察觉错误的代码，且易于在不引入新代码错误之下，对代码加以重构。
+最初，Rust 团队曾认为确保内存安全和防止并发问题，属于两个独立的挑战，要以不同方法解决。随着时间的推移，团队发现所有权与类型系统是一套强大的工具，有助于管理内存安全 *和* 并发问题！通过利用所有权和类型检查，Rust 中许多并发错误都变成了编译时错误，而非运行时错误。因此，就不再要咱们花费大量时间尝试重现运行时并发 bug 发生的具体情况，而是不正确的代码将拒绝编译，并给出解释问题的报错。这样，咱们就可以在编写代码时修复代码，而不是交付代码到生产后才发现。我们给 Rust 的这一方面称为 *无惧并发*。无惧并发允许咱们编写没有隐蔽错误，及可以在不引入新的 bug 下易于重构的代码。
 
-> **注意**：为简化起见，这里将把许多的这些问题，指为 *并发，concurrency*，而非称作更准确的 *并发及/或并行，concurrency and/or parallel*。若本书是有关并发及/或并行编程的书，那么咱们就会更为具体。对于本章，请在任何提及 *并发* 之处，在内心里将其以 *并发及/或并行* 代换。
+> **注意**：为了简化起见，我们将把许多的这些问题统称为 *并发，concurrent*，而非更精确的表述为 *并发和/或并行，concurrent and/or parallel*。在本章中，每当我们使用 *并发* 一词时，请在脑海中替换为 *并发和/或并行*。在下一章中，由于这一区分更为重要，届时我们将更加具体。
 
-许多语言在他们所提供的，用于解决并发问题的方案上，都是机械教条主义的。比如，Erlang 有着消息传递方面并发的优雅功能，但在共用线程间状态方面，却只有一些晦涩难懂的的途径，for example, Erlang has elegant functionality for message-passing concurrency, but has only obscure ways to share state between threads。对于这类高级语言来讲，仅支持可行方案的子集，是说得通的一种策略，这是由于高级语言以放弃部分的掌控，而换取到抽象方面的收益。然而，那些底层语言，则被期望在各种情形下，都要提供最具性能的方案，进而在硬件上有着较少抽象。因此，Rust 便提供了用以适合于咱们自己不同情形与需求的各种方式，对问题加以建模的各种工具，therefore, Rust offers a variety of tools for modeling problems in whatever way is appropriate for your situtation and requirements。
+许多语言在他们为解决并发问题提供的解决方案方面，都是机械教条主义的。例如，Erlang/OTP 虽然有着优雅的消息传递的并发功能，却只有一些晦涩难懂的的方式来在线程间共用状态。对于高级语言来说，仅支持可行方案的子集是一种合理策略，因为高级语言带来了通过放弃部分控制权以获取抽象的好处。然而，底层语言被期望要在各种给定情形下，都能提供有着最佳性能的方案，而有着对硬件的较少抽象。因此，Rust 提供了多种工具，以适合于咱们的情况和要求的方式建模问题。
 
-以下即为本章咱们将涵盖的几个话题：
+以下时我们将在这一章中介绍的几个话题：
 
-- 怎样创建出线程，来在同一时间运行代码的不同片段，how to create threads to run multiple pieces of code at the same time；
-
-- *消息传递，message-passing* 方面的并发，其中有着于线程间发送消息的一些通道；
-
-- *状态共用，shared-state* 方面的并发，其中多个线程均对某个数据加以访问；
-
-- `Sync` 与 `Send` 特质，他们俩把 Rust 并发方面的保证，扩展到 Rust 使用者所定义的类型，以及由标准库所提供的那些类型。
+- 怎样创建线程，以同时运行代码的多个部分（多段代码）；
+- 基于 *消息传递* 的并发，其中有着发送线程之间消息的通道；
+- 基于 *状态共用* 的并发，其中多个线程均有着对某一数据的访问权限；
+- `Sync` 与 `Send` 特质，他们扩展 Rust 的并发保证到用户定义的类型，以及标准库提供的类型。
 
 

src/smart_pointers/ref-cycles.md

@@ -234,7 +234,7 @@ leaf 的父节点 = Some(Node { value: 5, parent: RefCell { value: (Weak) }, chi
 没有无限输出表明，这段代码没有创建引用环。我们也可以通过查看调用 `Rc::strong_count` 和 `Rc::weak_count` 得到的值来判断这点。
 
 
-### 可视化 `strong_count` 到 `weak_count` 的变化
+### 可视化 `strong_count` 与 `weak_count` 的变化
 
 咱们来通过创建一个新的内层作用域，并迁移 `branch` 的创建到该作用域中，看看 `Rc<Node>` 实例的 `strong_count` 和 `weak_count` 值会如何变化。通过这样做，我们可以看到在 `branch` 被创建时，以及当他超出作用域而被弃用时，分别会发生什么。相关修改如下清单 15-29 中所示。