From 3d4d87d4eb93079ed30d4c3aaa5ff423e02d63b1 Mon Sep 17 00:00:00 2001 From: KaiserY Date: Wed, 22 Mar 2017 15:30:00 +0800 Subject: [PATCH] wip finish ch16 --- README.md | 2 +- docs/ch04-02-references-and-borrowing.html | 2 +- docs/ch04-03-slices.html | 2 +- docs/ch16-03-shared-state.html | 4 +- ...-extensible-concurrency-sync-and-send.html | 25 ++++++++++- docs/print.html | 31 ++++++++++++-- src/PREFACE.md | 2 +- src/ch16-03-shared-state.md | 6 ++- ...04-extensible-concurrency-sync-and-send.md | 41 +++++++++++++++++++ 9 files changed, 105 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 4631943..99233d2 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ # Rust 程序设计语言（第二版） 简体中文版 -还在施工中：正在翻译第十六章第二部分 +还在施工中：目前翻译到第十六章 目前正在解决代码排版问题：已检查到第五章 \ No newline at end of file diff --git a/docs/ch04-02-references-and-borrowing.html b/docs/ch04-02-references-and-borrowing.html index e5abf83..2785bf7 100644 --- a/docs/ch04-02-references-and-borrowing.html +++ b/docs/ch04-02-references-and-borrowing.html @@ -203,7 +203,7 @@ immutable

哇哦！我们也不能在拥有不可变引用的同时拥有可变引用。不可变引用的用户可不希望在它的眼皮底下值突然就被改变了！然而，多个不可变引用是没有问题的因为没有哪个读取数据的人有能力影响其他人读取到的数据。

即使这些错误有时是使人沮丧的。记住这是 Rust 编译器在提早指出一个潜在的 bug（在编译时而不是运行时）并明确告诉你问题在哪而不是任由你去追踪为何有时数据并不是你想象中的那样。

悬垂引用

 -

在存在指针的语言中，容易错误地生成一个悬垂指针（dangling pointer），一个引用某个内存位置的指针，这个内存可能已经因为被分配给别人，因为释放内存时指向内存的指针被保留了下来。相比之下，在 Rust 中编译器确保引用永远也不会变成悬垂状态：当我们拥有一些数据的引用，编译器确保数据不会在其引用之前离开作用域。

+

在存在指针的语言中，容易通过释放内存时保留指向它的指针而错误地生成一个悬垂指针（dangling pointer），所谓悬垂指针是其指向的内存可能已经被分配给其它持有者，。相比之下，在 Rust 中编译器确保引用永远也不会变成悬垂状态：当我们拥有一些数据的引用，编译器确保数据不会在其引用之前离开作用域。

让我们尝试创建一个悬垂引用：

Filename: src/main.rs

fn main() {
diff --git a/docs/ch04-03-slices.html b/docs/ch04-03-slices.html
index 0a061b8..2be23b4 100644
--- a/docs/ch04-03-slices.html
+++ b/docs/ch04-03-slices.html
@@ -109,7 +109,7 @@ byte index value into the String parameter

 }
 s.len()
-

现在有了一个找到字符串中第一个单词结尾索引的方法了，不过这有一个问题。我们返回了单单一个usize，不过它只在&String的上下文中才是一个有意义的数字。换句话说，因为它是一个与String像分离的值，无法保证将来它仍然有效。考虑一下列表 4-11 中使用了列表 4-10 first_word函数的程序：

+

现在有了一个找到字符串中第一个单词结尾索引的方法了，不过这有一个问题。我们返回了单单一个usize，不过它只在&String的上下文中才是一个有意义的数字。换句话说，因为它是一个与String相分离的值，无法保证将来它仍然有效。考虑一下列表 4-11 中使用了列表 4-10 first_word函数的程序：

Filename: src/main.rs

# fn first_word(s: &String) -> usize {
 #     let bytes = s.as_bytes();
diff --git a/docs/ch16-03-shared-state.html b/docs/ch16-03-shared-state.html
index 2623189..33c48f8 100644
--- a/docs/ch16-03-shared-state.html
+++ b/docs/ch16-03-shared-state.html
@@ -312,7 +312,9 @@ to be able to share ownership across multiple threads

成功了！我们从 0 数到了 10，这可能并不是很显眼，不过一路上我们学习了很多关于Mutex<T>和线程安全的内容！这个例子中构建的结构可以用于比增加计数更为复杂的操作。可以被分解为独立部分的计算可以像这样被分散到多个线程中，并可以使用Mutex<T>来允许每个线程在他们自己的部分更新最终的结果。

你可能注意到了，因为counter是不可变的，不过可以获取其内部值的可变引用，这意味着Mutex<T>提供了内部可变性，就像Cell系列类型那样。正如第十五章中使用RefCell<T>可以改变Rc<T>中的内容那样，同样的可以使用Mutex<T>来改变Arc<T>中的内容。

-

回忆一下Rc<T>并没有避免所有可能的问题：我们也讨论了当两个Rc<T>相互引用时的引用循环的可能性，这可能造成内存泄露。Mutex<T>有一个类似的 Rust 同样也不能避免的问题：死锁。死锁（deadlock）是一个场景中操作需要锁定两个资源，而两个线程分别拥有一个锁并永远相互等待的问题。如果

+

回忆一下Rc<T>并没有避免所有可能的问题：我们也讨论了当两个Rc<T>相互引用时的引用循环的可能性，这可能造成内存泄露。Mutex<T>有一个类似的 Rust 同样也不能避免的问题：死锁。死锁（deadlock）是一个场景中操作需要锁定两个资源，而两个线程分别拥有一个锁并永远相互等待的问题。如果你对这个主题感兴趣，尝试编写一个带有死锁的 Rust 程序，接着研究任何其他语言中使用互斥器的死锁规避策略并尝试在 Rust 中实现他们。标准库中Mutex<T>和MutexGuard的 API 文档会提供拥有的信息。

+

Rust 的类型系统和所有权确保了线程在更新共享值时拥有独占的访问权限，所以线程不会以一种不可预测的方式覆盖彼此的操作。为了和编译器一起使一切正确运行花了一些时间，不过我们节省了未来可能需要重现只在线程以特定顺序执行才会出现的诡异错误场景的时间。

+

接下来，为了丰富本章的内容，让我们讨论一下Send和Sync trait 以及如何对自定义类型使用他们。

diff --git a/docs/ch16-04-extensible-concurrency-sync-and-send.html b/docs/ch16-04-extensible-concurrency-sync-and-send.html index 27877a8..18351f4 100644 --- a/docs/ch16-04-extensible-concurrency-sync-and-send.html +++ b/docs/ch16-04-extensible-concurrency-sync-and-send.html @@ -67,7 +67,30 @@
- +

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

 +
+

ch16-04-extensible-concurrency-sync-and-send.md +
+commit 55b294f20fc846a13a9be623bf322d8b364cee77

+
+

Rust 的并发模型中一个有趣的方面是语言本身对并发知道的很少。我们讨论过的几乎所有内容都是标准库的一部分，而不是语言本身的内容。因为并不需要语言提供任何用于并发上下文中的内容，并发选择也不仅限于标准库或语言所提供的：我们可以编写自己的或使用别人编写的内容。

+

我们说了几乎所有内容都不在语言本身，那么位于语言本身的是什么呢？这是两个 trait，都位于std::marker：Sync和Send。

+

Send用于表明所有权可能被传送给其他线程

 +

Send标记 trait 表明类型的所有权可能被在线程间传递。几乎所有的 Rust 类型都是Send的，不过有一些例外。标准库中提供的一个不是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>时，代码就可以编译了。

+

任何完全由Send的类型组成的类型也会自动被标记为Send。几乎所有基本类型都是Send的，除了第十九章将会讨论的裸指针（raw pointer）之外。大部分标准库类型是Send的，除了Rc<T>之外。

+

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，甚至都不需要实现任何方法。他们只是用来加强并发相关的不可变行性的。

+

实现这些标记 trait 涉及到实现不安全的 Rust 代码。第十九章将会讲到如何使用不安全 Rust 代码；现在，重要的是在创建新的由不是Send和Sync的部分构成的并发类型时需要多加小心，以确保维持其安全保证。The Nomicon 中由更多关于这些保证和如何维持他们的信息。

+

总结

 +

这不会是本书最后一个出现并发的章节；第二十章的项目会在更现实的场景中使用这些概念，而不像本章中讨论的这些小例子。

+

正如我们提到的，因为 Rust 本身很少有处理并发的部分内容，有很多的并发方案都由 crate 实现。他们比标准库要发展的更快；请在网上搜索当前最新的用于多线程场景的 crate。

+

Rust 提供了用于消息传递的通道，和像Mutex<T>和Arc<T>这样可以安全的用于并发上下文的智能指针。类型系统和借用检查器会确保这些场景中的代码不会出现数据竞争和无效的引用。一旦代码可以编译了，我们就可以坚信这些代码可以正确的运行于多线程环境，而不会出现其他语言中经常出现的那些难以追踪的 bug。并发编程不再是什么可怕的概念：无所畏惧的使你的程序使用并发吧！

+

接下来，让我们讨论一下当 Rust 程序变得更大时那些符合习惯的模拟问题和结构的解决方案，以及 Rust 风格如何与面向对象编程（Object Oriented Programming）中那些你所熟悉的概念相联系。

+
diff --git a/docs/print.html b/docs/print.html index 9678893..3d43f04 100644 --- a/docs/print.html +++ b/docs/print.html @@ -1967,7 +1967,7 @@ immutable

哇哦！我们也不能在拥有不可变引用的同时拥有可变引用。不可变引用的用户可不希望在它的眼皮底下值突然就被改变了！然而，多个不可变引用是没有问题的因为没有哪个读取数据的人有能力影响其他人读取到的数据。

即使这些错误有时是使人沮丧的。记住这是 Rust 编译器在提早指出一个潜在的 bug（在编译时而不是运行时）并明确告诉你问题在哪而不是任由你去追踪为何有时数据并不是你想象中的那样。

悬垂引用

 -

在存在指针的语言中，容易错误地生成一个悬垂指针（dangling pointer），一个引用某个内存位置的指针，这个内存可能已经因为被分配给别人，因为释放内存时指向内存的指针被保留了下来。相比之下，在 Rust 中编译器确保引用永远也不会变成悬垂状态：当我们拥有一些数据的引用，编译器确保数据不会在其引用之前离开作用域。

+

在存在指针的语言中，容易通过释放内存时保留指向它的指针而错误地生成一个悬垂指针（dangling pointer），所谓悬垂指针是其指向的内存可能已经被分配给其它持有者，。相比之下，在 Rust 中编译器确保引用永远也不会变成悬垂状态：当我们拥有一些数据的引用，编译器确保数据不会在其引用之前离开作用域。

让我们尝试创建一个悬垂引用：

Filename: src/main.rs

fn main() {
@@ -2070,7 +2070,7 @@ byte index value into the String parameter

 }
 s.len()
-

现在有了一个找到字符串中第一个单词结尾索引的方法了，不过这有一个问题。我们返回了单单一个usize，不过它只在&String的上下文中才是一个有意义的数字。换句话说，因为它是一个与String像分离的值，无法保证将来它仍然有效。考虑一下列表 4-11 中使用了列表 4-10 first_word函数的程序：

+

现在有了一个找到字符串中第一个单词结尾索引的方法了，不过这有一个问题。我们返回了单单一个usize，不过它只在&String的上下文中才是一个有意义的数字。换句话说，因为它是一个与String相分离的值，无法保证将来它仍然有效。考虑一下列表 4-11 中使用了列表 4-10 first_word函数的程序：

Filename: src/main.rs

# fn first_word(s: &String) -> usize {
 #     let bytes = s.as_bytes();
@@ -9452,7 +9452,32 @@ to be able to share ownership across multiple threads

成功了！我们从 0 数到了 10，这可能并不是很显眼，不过一路上我们学习了很多关于Mutex<T>和线程安全的内容！这个例子中构建的结构可以用于比增加计数更为复杂的操作。可以被分解为独立部分的计算可以像这样被分散到多个线程中，并可以使用Mutex<T>来允许每个线程在他们自己的部分更新最终的结果。

你可能注意到了，因为counter是不可变的，不过可以获取其内部值的可变引用，这意味着Mutex<T>提供了内部可变性，就像Cell系列类型那样。正如第十五章中使用RefCell<T>可以改变Rc<T>中的内容那样，同样的可以使用Mutex<T>来改变Arc<T>中的内容。

-

回忆一下Rc<T>并没有避免所有可能的问题：我们也讨论了当两个Rc<T>相互引用时的引用循环的可能性，这可能造成内存泄露。Mutex<T>有一个类似的 Rust 同样也不能避免的问题：死锁。死锁（deadlock）是一个场景中操作需要锁定两个资源，而两个线程分别拥有一个锁并永远相互等待的问题。如果

+

回忆一下Rc<T>并没有避免所有可能的问题：我们也讨论了当两个Rc<T>相互引用时的引用循环的可能性，这可能造成内存泄露。Mutex<T>有一个类似的 Rust 同样也不能避免的问题：死锁。死锁（deadlock）是一个场景中操作需要锁定两个资源，而两个线程分别拥有一个锁并永远相互等待的问题。如果你对这个主题感兴趣，尝试编写一个带有死锁的 Rust 程序，接着研究任何其他语言中使用互斥器的死锁规避策略并尝试在 Rust 中实现他们。标准库中Mutex<T>和MutexGuard的 API 文档会提供拥有的信息。

+

Rust 的类型系统和所有权确保了线程在更新共享值时拥有独占的访问权限，所以线程不会以一种不可预测的方式覆盖彼此的操作。为了和编译器一起使一切正确运行花了一些时间，不过我们节省了未来可能需要重现只在线程以特定顺序执行才会出现的诡异错误场景的时间。

+

接下来，为了丰富本章的内容，让我们讨论一下Send和Sync trait 以及如何对自定义类型使用他们。

+

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

 +
+

ch16-04-extensible-concurrency-sync-and-send.md +
+commit 55b294f20fc846a13a9be623bf322d8b364cee77

+
+

Rust 的并发模型中一个有趣的方面是语言本身对并发知道的很少。我们讨论过的几乎所有内容都是标准库的一部分，而不是语言本身的内容。因为并不需要语言提供任何用于并发上下文中的内容，并发选择也不仅限于标准库或语言所提供的：我们可以编写自己的或使用别人编写的内容。

+

我们说了几乎所有内容都不在语言本身，那么位于语言本身的是什么呢？这是两个 trait，都位于std::marker：Sync和Send。

+

Send用于表明所有权可能被传送给其他线程

 +

Send标记 trait 表明类型的所有权可能被在线程间传递。几乎所有的 Rust 类型都是Send的，不过有一些例外。标准库中提供的一个不是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>时，代码就可以编译了。

+

任何完全由Send的类型组成的类型也会自动被标记为Send。几乎所有基本类型都是Send的，除了第十九章将会讨论的裸指针（raw pointer）之外。大部分标准库类型是Send的，除了Rc<T>之外。

+

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，甚至都不需要实现任何方法。他们只是用来加强并发相关的不可变行性的。

+

实现这些标记 trait 涉及到实现不安全的 Rust 代码。第十九章将会讲到如何使用不安全 Rust 代码；现在，重要的是在创建新的由不是Send和Sync的部分构成的并发类型时需要多加小心，以确保维持其安全保证。The Nomicon 中由更多关于这些保证和如何维持他们的信息。

+

总结

 +

这不会是本书最后一个出现并发的章节；第二十章的项目会在更现实的场景中使用这些概念，而不像本章中讨论的这些小例子。

+

正如我们提到的，因为 Rust 本身很少有处理并发的部分内容，有很多的并发方案都由 crate 实现。他们比标准库要发展的更快；请在网上搜索当前最新的用于多线程场景的 crate。

+

Rust 提供了用于消息传递的通道，和像Mutex<T>和Arc<T>这样可以安全的用于并发上下文的智能指针。类型系统和借用检查器会确保这些场景中的代码不会出现数据竞争和无效的引用。一旦代码可以编译了，我们就可以坚信这些代码可以正确的运行于多线程环境，而不会出现其他语言中经常出现的那些难以追踪的 bug。并发编程不再是什么可怕的概念：无所畏惧的使你的程序使用并发吧！

+

接下来，让我们讨论一下当 Rust 程序变得更大时那些符合习惯的模拟问题和结构的解决方案，以及 Rust 风格如何与面向对象编程（Object Oriented Programming）中那些你所熟悉的概念相联系。

diff --git a/src/PREFACE.md b/src/PREFACE.md index 4631943..99233d2 100644 --- a/src/PREFACE.md +++ b/src/PREFACE.md @@ -1,5 +1,5 @@ # Rust 程序设计语言（第二版） 简体中文版 -还在施工中：正在翻译第十六章第二部分 +还在施工中：目前翻译到第十六章 目前正在解决代码排版问题：已检查到第五章 \ No newline at end of file diff --git a/src/ch16-03-shared-state.md b/src/ch16-03-shared-state.md index d2a4bed..5280f8d 100644 --- a/src/ch16-03-shared-state.md +++ b/src/ch16-03-shared-state.md @@ -307,4 +307,8 @@ Result: 10 你可能注意到了，因为`counter`是不可变的，不过可以获取其内部值的可变引用，这意味着`Mutex`提供了内部可变性，就像`Cell`系列类型那样。正如第十五章中使用`RefCell`可以改变`Rc`中的内容那样，同样的可以使用`Mutex`来改变`Arc`中的内容。 -回忆一下`Rc`并没有避免所有可能的问题：我们也讨论了当两个`Rc`相互引用时的引用循环的可能性，这可能造成内存泄露。`Mutex`有一个类似的 Rust 同样也不能避免的问题：死锁。**死锁**（*deadlock*）是一个场景中操作需要锁定两个资源，而两个线程分别拥有一个锁并永远相互等待的问题。如果 \ No newline at end of file +回忆一下`Rc`并没有避免所有可能的问题：我们也讨论了当两个`Rc`相互引用时的引用循环的可能性，这可能造成内存泄露。`Mutex`有一个类似的 Rust 同样也不能避免的问题：死锁。**死锁**（*deadlock*）是一个场景中操作需要锁定两个资源，而两个线程分别拥有一个锁并永远相互等待的问题。如果你对这个主题感兴趣，尝试编写一个带有死锁的 Rust 程序，接着研究任何其他语言中使用互斥器的死锁规避策略并尝试在 Rust 中实现他们。标准库中`Mutex`和`MutexGuard`的 API 文档会提供拥有的信息。 + +Rust 的类型系统和所有权确保了线程在更新共享值时拥有独占的访问权限，所以线程不会以一种不可预测的方式覆盖彼此的操作。为了和编译器一起使一切正确运行花了一些时间，不过我们节省了未来可能需要重现只在线程以特定顺序执行才会出现的诡异错误场景的时间。 + +接下来，为了丰富本章的内容，让我们讨论一下`Send`和`Sync` trait 以及如何对自定义类型使用他们。 \ No newline at end of file diff --git a/src/ch16-04-extensible-concurrency-sync-and-send.md b/src/ch16-04-extensible-concurrency-sync-and-send.md index e69de29..b9f3bde 100644 --- a/src/ch16-04-extensible-concurrency-sync-and-send.md +++ b/src/ch16-04-extensible-concurrency-sync-and-send.md @@ -0,0 +1,41 @@ +## 使用`Sync`和`Send` trait 的可扩展并发 + +> [ch16-04-extensible-concurrency-sync-and-send.md](https://github.com/rust-lang/book/blob/master/second-edition/src/ch16-04-extensible-concurrency-sync-and-send.md) +>
+> commit 55b294f20fc846a13a9be623bf322d8b364cee77 + +Rust 的并发模型中一个有趣的方面是语言本身对并发知道的**很少**。我们讨论过的几乎所有内容都是标准库的一部分，而不是语言本身的内容。因为并不需要语言提供任何用于并发上下文中的内容，并发选择也不仅限于标准库或语言所提供的：我们可以编写自己的或使用别人编写的内容。 + +我们说了**几乎**所有内容都不在语言本身，那么位于语言本身的是什么呢？这是两个 trait，都位于`std::marker`：`Sync`和`Send`。 + +### `Send`用于表明所有权可能被传送给其他线程 + +`Send`标记 trait 表明类型的所有权可能被在线程间传递。几乎所有的 Rust 类型都是`Send`的，不过有一些例外。标准库中提供的一个不是`Send`的类型是`Rc`：如果克隆`Rc`值并尝试将克隆的所有权传递给另一个线程，这两个线程可能会同时更新引用计数。正如上一部分提到的，`Rc`被实现为用于单线程场景，这时不需要为拥有线程安全的引用计数而付出性能代价。 + +因为`Rc`没有标记为`Send`，Rust 的类型系统和 trait bound 会确保我们永远也不会忘记或错误的把一个`Rc`值不安全的在线程间传递。列表 16-14 曾尝试这么做，不过得到了一个错误说`the trait Send is not implemented for Rc>`。当切换为标记为`Send`的`Arc`时，代码就可以编译了。 + +任何完全由`Send`的类型组成的类型也会自动被标记为`Send`。几乎所有基本类型都是`Send`的，除了第十九章将会讨论的裸指针（raw pointer）之外。大部分标准库类型是`Send`的，除了`Rc`之外。 + +### `Sync`表明多线程访问是安全的 + +`Sync`标记 trait 表明一个类型可以安全的在多个线程中拥有其值的引用。换一种方式来说就是对于任意类型`T`，如果`&T`（`T`的引用）是`Send`的话`T`就是`Sync`的，这样其引用就可以安全的发送到另一个线程。类似于`Send`的情况，基本类型是`Sync`的，完全由`Sync`的类型组成的类型也是`Sync`的。 + +`Rc`也不是`Sync`的，出于其不是`Send`的相同的原因。`RefCell`（第十五章讨论过）和`Cell`系列类型不是`Sync`的。`RefCell`在运行时所进行的借用检查也不是线程安全的。`Mutex`是`Sync`的，正如上一部分所讲的它可以被用来在多线程中共享访问。 + +### 手动实现`Send`和`Sync`是不安全的 + +通常并不需要实现`Send`和`Sync` trait，因为由是`Send`和`Sync`的类型组成的类型也自动就是`Send`和`Sync`的了。因为他们是标记 trait，甚至都不需要实现任何方法。他们只是用来加强并发相关的不可变行性的。 + +实现这些标记 trait 涉及到实现不安全的 Rust 代码。第十九章将会讲到如何使用不安全 Rust 代码；现在，重要的是在创建新的由不是`Send`和`Sync`的部分构成的并发类型时需要多加小心，以确保维持其安全保证。[The Nomicon] 中由更多关于这些保证和如何维持他们的信息。 + +[The Nomicon]: https://doc.rust-lang.org/stable/nomicon/vec.html + +## 总结 + +这不会是本书最后一个出现并发的章节；第二十章的项目会在更现实的场景中使用这些概念，而不像本章中讨论的这些小例子。 + +正如我们提到的，因为 Rust 本身很少有处理并发的部分内容，有很多的并发方案都由 crate 实现。他们比标准库要发展的更快；请在网上搜索当前最新的用于多线程场景的 crate。 + +Rust 提供了用于消息传递的通道，和像`Mutex`和`Arc`这样可以安全的用于并发上下文的智能指针。类型系统和借用检查器会确保这些场景中的代码不会出现数据竞争和无效的引用。一旦代码可以编译了，我们就可以坚信这些代码可以正确的运行于多线程环境，而不会出现其他语言中经常出现的那些难以追踪的 bug。并发编程不再是什么可怕的概念：无所畏惧的使你的程序使用并发吧！ + +接下来，让我们讨论一下当 Rust 程序变得更大时那些符合习惯的模拟问题和结构的解决方案，以及 Rust 风格如何与面向对象编程（Object Oriented Programming）中那些你所熟悉的概念相联系。 \ No newline at end of file