std::io::Stdout::lock() 去确保输出没有被中断。println!() 将等待直到任意并发地运行完成后，在写入输出。如果不是这样，我们可以得到更多的交叉输出：
+ println 宏使用 std::io::Stdout::lock() 去确保输出没有被中断。println!() 表达式将等待直到任意并发的表达式运行完成后，再写入输出。如果不是这样，我们可能得到更多的交错输出：
Hello fromHello from another thread! @@ -107,7 +107,7 @@ This is my thread id: ThreadId(3) id: ThreadId(3)
std::thread::Builder 允许你在产生线程之前为新线程设置一些设置。你可以使用它为新线程配置栈大小并给新线程一个名字。线程的名字是可以通过 std::thread::current().name() 获得，这将在 panic 消息中可用，并在监控和大多数雕饰工具中可见。
此外，Builder 的产生函数返回一个 std::io::Result，允许你处理新线程失败的情况。如果操作系统内存不足，或者资源限制已经应用于你对程序，这是可能发生的。如果 std::thread::spawn 函数不能去产生一个新线程，它只会 panic。
此外，Builder 的产生函数返回一个 std::io::Result，允许你处理产生新线程失败的情况。如果操作系统内存不足，或者资源限制已经应用于你的程序，这是可能发生的。如果 std::thread::spawn 函数不能去产生一个新线程，它就会 panic。
在 Rust 1.0 之前，标准库有一个函数叫做 std::thread::scoped，它将直接产生一个线程，就像 std::thread::spawn。它允许无 'static 的捕获，因为它返回的不是 JoinGuard，而是当被 drop 时 join 到线程的 JoinGuard。任意的借用数据仅需要比这个 JoinGuard 活得更久。只要 JoinGuard 在某个时候被 drop，这似乎是安全的。
在 Rust 1.0 之前，标准库有一个函数叫做 std::thread::scoped，它将直接产生一个线程，就像 std::thread::spawn。它允许无 'static 的捕获，因为它返回的不是 JoinHandle，而是当被 drop 时 join 到线程的 JoinGuard。任意的借用数据仅需要比这个 JoinGuard 活得更久。只要 JoinGuard 在某个时候被 drop，这似乎是安全的。
就在 Rust 1.0 发布之前，人们慢慢发现它似乎不能保证某些东西被 drop。有很多种方式没有 drop 它，例如创建一个引用计数节点的循环，可以忘记某些东西或者*泄漏*它。
@@ -226,11 +226,11 @@ error[E0499]: cannot borrow `numbers` as mutable more than once at a time ## 共享所有权以及引用计数 -目前，我们已经使用了 `move` 闭包（[“Rust 中的线程”](#rust-中的线程)）将值的所有权转移到线程并从生命周期较长的父线程借用数据（[“线程作用域”](#线程作用域)）。当两个线程之间共享数据，它们之间的任何一个线程都不能保证比另一个线程的生命周期长，那么它们都不能称为该数据的所有者。它们之间共享的任何数据都需要与最长生命周期的线程一样长。 +目前，我们已经使用了 `move` 闭包（[“Rust 中的线程”](#rust-中的线程)）将值的所有权转移到线程并从生命周期较长的父线程借用数据（[作用域内的线程](#作用域内的线程)）。当两个线程之间共享数据，它们之间的任何一个线程都不能保证比另一个线程的生命周期长，那么它们都不能称为该数据的所有者。它们之间共享的任何数据都需要与最长生命周期的线程一样长。 ### Static -有几种方式去创建不属于单线程的东西。最简单的方式是**静态**值，它由整个程序“拥有”，而不是单个线程。在以下示例中，这两个线程都可以获取 X，但是它们并不能拥有它： +有几种方式去创建不属于单线程的东西。最简单的方式是**静态**值，它由整个程序“拥有”，而不是单个线程。在以下示例中，这两个线程都可以获取 X，但是它们并不拥有它： ```rust static X: [i32; 3] = [1, 2, 3]; @@ -262,7 +262,7 @@ thread::spawn(move || dbg!(x)); ### 引用计数 -为了确保共享数据能够 drop 和取消分配，我们不能完全放弃它的所有权。相反，我们可以*分享所有权*。通过跟踪所有者的数量，我们确保仅当没有所有者时，才会丢弃该值。 +为了确保共享数据能够 drop 和释放内存，我们不能完全放弃它的所有权。相反，我们可以*分享所有权*。通过跟踪所有者的数量，我们确保仅当没有所有者时，才会丢弃该值。 Rust 标准库通过 `std::rc::Rc` 类型提供了该功能，它是“引用计数”（reference counted）的缩写。它与 `Box` 非常类似，唯一的区别是克隆它将不会分配任何新内存，而是增加存储在包含值旁边的计数器。原始的 `Rc` 和克隆的 `Rc` 将引用相同的内存分配；它们*共享所有权*。 @@ -376,7 +376,7 @@ fn f(a: &i32, b: &mut i32) { 这里，我们得到一个整数的不可变引用，并在增加 b 所引用的整数进行递增操作之前和之后存储整数的值。编译器可以自由地假设关于借用和数据竞争的基本规则得到了遵守，这意味着 b 不可能引用与 a 相同的整数。实际上，在对 a 进行借用时，整个程序中没有任何地方对 a 借用的整数进行可变借用。因此，编译器可以轻松地推断 `*a` 不会发生变化，并且 `if` 语句将永远不是 true，并且可以作为优化完全地删除 x 调用。 -除了使用一个不安全的块（`unsafe`）去禁止一些编译器安全地检查，否则不可能去写 Rust 程序打断编译器的假设。 +除了使用不安全的块（`unsafe`）禁止一些编译器的安全检查之外，不可能写出编译器出乎意料的 Rust 程序。在 Rust 中，仅当使用 unsafe 代码块才能打破这些规则。“unsafe”并不意味着代码是错误的或者错位安全使用，而是编译器并没有为你验证代码是安全的。如果代码却是违法了这些规则，则称为不健全的（unsound）。
-允许编译器在不检查的情况下假设这些规则从未破坏。当破坏是，这将导致叫做为定义行为的问题，我们需要不惜一切代价去避免。如果我们允许编译器作出与实际不符的假设，那么它可能很容易导致关于代码不同部分更错误的结论，影响你整个程序。
+允许编译器在不检查的情况下假设这些规则从未破坏。当破坏是，这将导致叫做未定义行为的问题，我们需要不惜一切代价去避免。如果我们允许编译器作出与实际不符的假设，那么它可能很容易导致关于代码不同部分更错误的结论，影响你整个程序。
作为一个具体的例子，让我们看看在切片上使用 get_unchecked 方法的小片段：
let a = [123, 456, 789];
let b = unsafe { a.get_unchecked(index) };
- get_unchecked 方法给我们一个给定索引的切片元素，就像 a[index]，但是允许变异器假设索引总是在边界，没有任何检查。
get_unchecked 方法给我们一个给定索引的切片元素，就像 a[index]，但是允许编译器假设索引总是在边界，没有任何检查。
这意味着，在代码片段中，由于 a 的长度是 3，编译器可能假设索引小雨 3。这使我们确保其假设成立。
+这意味着，在代码片段中，由于 a 的长度是 3，编译器可能假设索引小于 3。这使我们确保其假设成立。
如果我们破坏了这个假设，例如，我们以等于 3 的索引运行，任何事情都可能发生。它可能导致读取 a 之后存储的任何内存内容。这可能导致程序崩溃。它可能会执行程序中完全无关的部分。它可能会引起各种糟糕的情况。
-或许令人惊讶的是，为定义行为可能“回到过去”，导致之前的代码出问题。要理解这种情况是如何发生的，想象我们上面的片段有一个 match 语句，如下：
+或许令人惊讶的是，未定义行为甚至可以“时间回溯”，导致之前的代码出问题。要理解这种情况是如何发生的，想象我们上面的片段有一个 match 语句，如下：
match index {
0 => x(),
@@ -408,11 +408,11 @@ let b = unsafe { a.get_unchecked(index) };
let a = [123, 456, 789];
let b = unsafe { a.get_unchecked(index) };
- 由于不安全的代码，允许编译器假设索引只有 0、1 或 2。从逻辑上讲，我们的 match 语句的最后分支仅会匹配到 2，因此 z 仅会调用为 z(2)。这个结论不仅可以优化匹配，还可以优化 z 本身。这可以扔掉代码中未使用的部分。
由于不安全的代码，编译器被允许假设索引只有 0、1 或 2。它可能会逻辑的得出结论，我们的 match 语句的最后分支仅会匹配到 2，因此 z 仅会调用为 z(2)。这个结论不仅可以优化匹配，还可以优化 z 本身。这可能包括丢弃代码中未使用的部分。
如果我们以 3 的索引执行此设置，我们的程序试图去执行已优化的部分，导致完全地为定义行为，这还远在我们到达最后一行不安全的块之前。就像这样，未定义行为通过整个程序向后或者向前传播，通过非常意想不到的方式传播。
+如果我们以 3 为索引执行此设置，我们的程序可能会尝试执行被优化的部分，导致在我们到达最后一行的不安全块之前就出现不可预测的行为。就像这样，未定义行为通过整个程序向后或者向前传播，而这往往是以非常出乎意料的方式发生的。
-当调用任何的不安全函数时，读它的文档并确保你完全理解它的安全需求：作为调用者，你需要坚持的假设，以避免未定义行为。
+当调用任何的不安全函数时，仔细阅读其文档，确保你完全理解它的安全要求：作为调用者，你需要维持的假设，以避免未定义行为。
下一篇，第二章：Atomic diff --git a/2_Atomics.md b/2_Atomics.md index c813682..18d0340 100644 --- a/2_Atomics.md +++ b/2_Atomics.md @@ -108,7 +108,7 @@ fn main() { } ``` -这次，我们使用一个[线程作用域](./1_Basic_of_Rust_Concurrency.md#线程作用域)，它将自动地为我们处理线程的 join，并且也允许我们借用局部变量。 +这次，我们使用一个[作用域内的线程](./1_Basic_of_Rust_Concurrency.md#作用域内的线程)，它将自动地为我们处理线程的 join，并且也允许我们借用局部变量。 每次后台线程完成处理项时，它都会将处理的项目数量存储在 AtomicUsize 中。与此同时，主线程向用户显示该数字，告知该进度，大约每秒一次。一旦主线程看见所有 10 项已经被处理，它就会退出作用域，它会隐式地 join 后台线程，并且告知用户所有都完成。 diff --git a/3_Memory_Ordering.md b/3_Memory_Ordering.md index eb78b23..d0dfc13 100644 --- a/3_Memory_Ordering.md +++ b/3_Memory_Ordering.md @@ -278,17 +278,17 @@ fn main() {
想象一下，两个线程都将一个 7 release-store 到相同的原子变量中，第三个线程从该变量中加载 7。第三个线程和第一个或者第二个线程有一个 happens-before 关系吗？这取决于它加载“哪个 7”：线程一还是线程二的。（或许一个不相关的 7）。这使我们得出的结论是，尽管 7 等于 7，但两个 7 与两个线程有一些不同。
-思考这个问题的方式是我们在[“Relaxed 排序”](#relaxed-排序)中讨论的*总修改顺序*：发生在原子变量上的所有修改的有序列表。即使将相同的值多次写入相同的变量，这些操作中的每一个都以该变量的总修改顺序代表一个单独的事件。当我们加载一个值，加载的值与每个变量“时间线”上的特定点相匹配，这告诉我们我们可能会同步哪个操作。
+思考这个问题的方式是我们在“Relaxed 排序”中讨论的*总修改顺序*：发生在原子变量上的所有修改的有序列表。即使将相同的值多次写入相同的变量，这些操作中的每一个都以该变量的总修改顺序代表一个单独的事件。当我们加载一个值，加载的值与每个变量“时间线”上的特定点相匹配，这告诉我们我们可能会同步哪个操作。
例如，如果原子总修改顺序是
- 1. 初始化为 0 +1. 初始化为 0
- 2. Release-store 7（来自线程二） +2. Release-store 7（来自线程二）
- 3. Release-store 6 +3. Release-store 6
- 4. Release-store 7（来自线程一） +4. Release-store 7（来自线程一）
然后，acquire-load 7 将与第二个线程的 release-store 或者最后一个事件的 release-store 同步。然而，如果我们之前（就 happens-before 关系而言）见过 6，我们知道我们看到的是最后一个 7，而不是第一个 7，这意味着我们现在与线程一有 happens-before 的关系，而不是线程二。
@@ -296,17 +296,17 @@ fn main() {例如，想象一个具有以下总修改顺序的原子变量：
- 1. 初始化为 0 +1. 初始化为 0
- 2. Release-store 7 +2. Release-store 7
- 3. Relaxed-fetch-and-add 1，改变 7 到 8 +3. Relaxed-fetch-and-add 1，改变 7 到 8
- 4. Relaxed-fetch-and-add 1，改变 8 到 9 +4. Relaxed-fetch-and-add 1，改变 8 到 9
- 5. Release-store 7 +5. Release-store 7
- 6. Relaxed-swap 10，改变 7 到 10 +6. Relaxed-swap 10，改变 7 到 10
现在，如果我们在这个变量上执行 acquire-load 到 9，我们不仅与第四个操作（存储此值）建立了一个 happens-before 关系，同时也与第二个操作（存储 7）建立了该关系，即使第三个操作使用了 Relaxed 内存排序。
diff --git a/5_Building_Our_Own_Channels.md b/5_Building_Our_Own_Channels.md index 99cd244..8d1ee8e 100644 --- a/5_Building_Our_Own_Channels.md +++ b/5_Building_Our_Own_Channels.md @@ -1,19 +1,739 @@ # 第五章：构建我们自己的 Channel +*Channel* 可以被用于在线程之间发送数据，并且它们有很多变体。一些 channel 仅能在一个发送者和一个接收者之间使用，而另一些可以在任意数量的线程之间发送，或者甚至允许多个接收者。一些 channel 是阻塞的，这意味着接收（有时也包括发送）是一个阻塞操作，这会使线程进入睡眠状态，知道你的操作完成。一些 channel 针对团兔粮进行优化，而另一些针对低延迟进行优化。 + +这些变体是无穷尽的，没有一种通用版本在所有场景都适合的。 + +在该章节，我们将实现一个相对简单的 channel，不仅可以探索更多的原子应用，同时也可以了解如何在 Rust 类型系统中捕获我们的需求和假设。 + ## 一个简单的以 mutex 为基础的 Channel +一个基础的 channel 实现并不需要任何关于原子的知识。我们可以采用 `VecDeque`，它根本上是一个 `Vec`，允许在两端高效的添加和移除元素，并使用 Mutex 保护它，以允许多个线程访问。然后，我们使用 `VecDeque` 作为已发送但尚未接受数据的消息队列。任何想要发送消息的线程只需要将其添加到队列的末尾，而任何想要接受消息的线程只需从队列的前端删除一个消息。 + +还有一件事需要补充，用于使接收操作阻塞：Condvar（参见[第一章“条件变量”](./1_Basic_of_Rust_Concurrency.md#条件变量)），以通知等待接收者新的消息。 + +这样做的实现可能非常简短且相对简单，如下所示： + +```rust +pub struct Channel如果你对 channel 实现还不满意，这里有一个微妙的变体，可以节省一字节的内存。
+ +我们使用单个原子 AtomicU8 表示所有 4 个状态，而不是使用两个分开的布尔值去表示 channel 的状态。我们必须使用 compare_exchange 来原子地检查 channel 是否处于预期状态，并将其更改为另一个状态，而不是原子交换布尔值。