跟随上游 PR #431 更新

src/intro.md

@@ -15,7 +15,7 @@
 >
 > 如果大家对于翻译有更好的建议或者想法，欢迎直接 PR~
 >
-> 目前翻译基于 commit：1842257814919fa62e81bdecd5e8f95be2839dbb，基于时间：2023/10/17
+> 目前翻译基于 commit：83d015105e6d490fc30d6c95da1e56152a50e228，基于时间：2023/11/23
 >
 > Q：为什么不基于之前已有的中文版进行改进？
 >

src/races.md

@@ -6,11 +6,11 @@
 * 其中一个或多个线程是写的
 * 其中一个或多个是非同步的
 
-数据竞争具有未定义行为，因此在 Safe Rust 中不可能执行。数据竞争主要是通过 Rust 的所有权系统来防止的：不可能别名一个可变引用，所以不可能进行数据竞争。但内部可变性使其更加复杂，这也是我们有 Send 和 Sync Trait 的主要原因（见下文）。
+数据竞争具有未定义行为，因此在 Safe Rust 中不可能执行。数据竞争主要是通过 Rust 的所有权系统来防止的：不可能别名一个可变引用，所以不可能进行数据竞争。但内部可变性使其更加复杂，这也是我们有 Send 和 Sync Trait 的主要原因（见下个章节更详细的说明）。
 
 **然而，Rust 并没有（也无法）阻止更广泛的竞态条件。**
 
-这从根本上说是不可能的，而且说实话也是不可取的。你的硬件很糟糕，你的操作系统很糟糕，你电脑上的其他程序也很糟糕，而这一切运行的世界也很糟糕。任何能够真正声称防止*所有*竞态条件的系统，如果不是不正确的话，使用起来也是非常糟糕的。
+在你无法控制调度器的情况下，这在数学上是不可能的，而对于普通的操作系统环境来说你是无法控制调度器的。如果你确实控制了抢占，那么 _有可能_ 防止一般的竞态——这种技术被像 [RTIC](https://github.com/rtic-rs/rtic) 这样的框架所使用。然而，实际上拥有对调度的控制是一个非常罕见的情况。
 
 因此，对于一个安全的 Rust 程序来说，在不正确的同步下出现死锁或做一些无意义的事情是完全“正常”的。很明显，这样的程序有问题，但 Rust 只能帮你到这里。不过，Rust 程序中的竞态条件本身并不能违反内存安全；只有与其他不安全的代码结合在一起，竞态条件才能真正违反内存安全。比如说：
 
@@ -40,6 +40,8 @@ thread::spawn(move || {
 println!("{}", data[idx.load(Ordering::SeqCst)]);
 ```
 
+如果我们提前进行边界检查，然后使用未经检查的值不安全地访问数据，我们就可能引起数据竞争：
+
 ```rust,no_run
 use std::thread;
 use std::sync::atomic::{AtomicUsize, Ordering};