Merge pull request #37 from murphil/murphy

修订：使用Sync和Send trait 的可扩展并发

src/ch16-04-extensible-concurrency-sync-and-send.md

@@ -4,29 +4,29 @@
 > <br>
 > commit 55b294f20fc846a13a9be623bf322d8b364cee77
 
-Rust 的并发模型中一个有趣的方面是语言本身对并发知道的**很少**。我们讨论过的几乎所有内容都是标准库的一部分，而不是语言本身的内容。因为并不需要语言提供任何用于并发上下文中的内容，并发选择也不仅限于标准库或语言所提供的：我们可以编写自己的或使用别人编写的内容。
+Rust 的并发模型中一个有趣的方面是：语言本身对并发知道的**很少**。几乎我们之前讨论的所有内容，都是标准库的一部分，而不是语言本身的内容。因为并不需要语言提供任何用于并发上下文中的内容，并发选择也不仅限于标准库或语言所提供的：我们可以编写自己的或使用别人编写的内容。
 
-我们说了**几乎**所有内容都不在语言本身，那么位于语言本身的是什么呢？这是两个 trait，都位于`std::marker`:`Sync`和`Send`。
+我们说“**几乎**所有内容都不属于语言本身”，那么属于语言本身的是什么呢？是两个 trait，都位于`std::marker`： `Sync`和`Send`。
 
 ### `Send`用于表明所有权可能被传送给其他线程
 
-`Send`标记 trait 表明类型的所有权可能被在线程间传递。几乎所有的 Rust 类型都是`Send`的，不过有一些例外。标准库中提供的一个不是`Send`的类型是`Rc<T>`：如果克隆`Rc<T>`值并尝试将克隆的所有权传递给另一个线程，这两个线程可能会同时更新引用计数。正如上一部分提到的，`Rc<T>`被实现为用于单线程场景，这时不需要为拥有线程安全的引用计数而付出性能代价。
+`Send`标记 trait 表明类型的所有权可能被在线程间传递。几乎所有的 Rust 类型都是`Send`的，不过有一些例外。比如标准库中提供的 `Rc<T>`：如果克隆`Rc<T>`值，并尝试将克隆的所有权传递给另一个线程，这两个线程可能会同时更新引用计数。正如上一部分提到的，`Rc<T>`被实现为用于单线程场景，这时不需要为拥有线程安全的引用计数而付出性能代价。
 
-因为`Rc<T>`没有标记为`Send`，Rust 的类型系统和 trait bound 会确保我们永远也不会忘记或错误的把一个`Rc<T>`值不安全的在线程间传递。列表 16-14 曾尝试这么做，不过得到了一个错误说`the trait Send is not implemented for Rc<Mutex<i32>>`。当切换为标记为`Send`的`Arc<T>`时，代码就可以编译了。
+因为`Rc<T>`没有标记为`Send`，Rust 的类型系统和 trait bound 会确保我们不会错误的把一个`Rc<T>`值不安全的在线程间传递。列表 16-14 曾尝试这么做，不过得到了一个错误，`the trait Send is not implemented for Rc<Mutex<i32>>`。当切换为标记为`Send`的`Arc<T>`时，就没有问题了。
 
-任何完全由`Send`的类型组成的类型也会自动被标记为`Send`。几乎所有基本类型都是`Send`的，除了第十九章将会讨论的裸指针（raw pointer）之外。大部分标准库类型是`Send`的，除了`Rc<T>`之外。
+任何完全由`Send`的类型组成的类型也会自动被标记为`Send`。几乎所有基本类型都是`Send`的，大部分标准库类型是`Send`的，除了`Rc<T>`，以及第十九章将会讨论的裸指针（raw pointer）。
 
 ### `Sync`表明多线程访问是安全的
 
-`Sync`标记 trait 表明一个类型可以安全的在多个线程中拥有其值的引用。换一种方式来说就是对于任意类型`T`，如果`&T`（`T`的引用）是`Send`的话`T`就是`Sync`的，这样其引用就可以安全的发送到另一个线程。类似于`Send`的情况，基本类型是`Sync`的，完全由`Sync`的类型组成的类型也是`Sync`的。
+`Sync`标记 trait 表明一个类型可以安全的在多个线程中拥有其值的引用。换一种方式来说就是，对于任意类型`T`，如果`&T`（`T`的引用）是`Send`的话`T`就是`Sync`的，这样其引用就可以安全的发送到另一个线程。类似于`Send`的情况，基本类型是`Sync`的，完全由`Sync`的类型组成的类型也是`Sync`的。
 
 `Rc<T>`也不是`Sync`的，出于其不是`Send`的相同的原因。`RefCell<T>`（第十五章讨论过）和`Cell<T>`系列类型不是`Sync`的。`RefCell<T>`在运行时所进行的借用检查也不是线程安全的。`Mutex<T>`是`Sync`的，正如上一部分所讲的它可以被用来在多线程中共享访问。
 
 ### 手动实现`Send`和`Sync`是不安全的
 
-通常并不需要实现`Send`和`Sync` trait，因为由是`Send`和`Sync`的类型组成的类型也自动就是`Send`和`Sync`的了。因为他们是标记 trait，甚至都不需要实现任何方法。他们只是用来加强并发相关的不可变性的。
+通常并不需要实现`Send`和`Sync` trait，由属于`Send`和`Sync`的类型组成的类型，自动就是`Send`和`Sync`的。因为他们是标记 trait，甚至都不需要实现任何方法。他们只是用来加强并发相关的不可变性的。
 
-实现这些标记 trait 涉及到实现不安全的 Rust 代码。第十九章将会讲到如何使用不安全 Rust 代码；现在，重要的是在创建新的由不是`Send`和`Sync`的部分构成的并发类型时需要多加小心，以确保维持其安全保证。[The Nomicon] 中有更多关于这些保证以及如何维持他们的信息。
+实现这些标记 trait 涉及到编写不安全的 Rust 代码，第十九章将会讲述具体的方法；当前重要的是，在创建新的由不是`Send`和`Sync`的部分构成的并发类型时需要多加小心，以确保维持其安全保证。[The Nomicon] 中有更多关于这些保证以及如何维持他们的信息。
 
 [The Nomicon]: https://doc.rust-lang.org/stable/nomicon/vec.html
 
@@ -36,6 +36,6 @@ Rust 的并发模型中一个有趣的方面是语言本身对并发知道的**
 
 正如我们提到的，因为 Rust 本身很少有处理并发的部分内容，有很多的并发方案都由 crate 实现。他们比标准库要发展的更快；请在网上搜索当前最新的用于多线程场景的 crate。
 
-Rust 提供了用于消息传递的通道，和像`Mutex<T>`和`Arc<T>`这样可以安全的用于并发上下文的智能指针。类型系统和借用检查器会确保这些场景中的代码不会出现数据竞争和无效的引用。一旦代码可以编译了，我们就可以坚信这些代码可以正确的运行于多线程环境，而不会出现其他语言中经常出现的那些难以追踪的 bug。并发编程不再是什么可怕的概念：无所畏惧地让你的程序使用并发吧！
+Rust 提供了用于消息传递的通道，和像`Mutex<T>`和`Arc<T>`这样可以安全的用于并发上下文的智能指针。类型系统和借用检查器会确保这些场景中的代码，不会出现数据竞争和无效的引用。一旦代码可以编译了，我们就可以坚信这些代码可以正确的运行于多线程环境，而不会出现其他语言中经常出现的那些难以追踪的 bug。并发编程不再是什么可怕的概念：无所畏惧地并发吧！
 
-接下来，让我们讨论一下当 Rust 程序变得更大时有哪些符合语言习惯的问题建模和节构化解决方案的做法，以及 Rust 的风格是如何与面向对象编程（Object Oriented Programming）中那些你所熟悉的概念相联系的。
+接下来，让我们讨论一下当 Rust 程序变得更大时，有哪些符合语言习惯的问题建模方法和结构化解决方案，以及 Rust 的风格是如何与面向对象编程（Object Oriented Programming）中那些你所熟悉的概念相联系的。