update original

Author: funkill

rustbook-en/nostarch/chapter16.md

@@ -18,21 +18,21 @@ than making you spend lots of time trying to reproduce the exact circumstances
 under which a runtime concurrency bug occurs, incorrect code will refuse to
 compile and present an error explaining the problem. As a result, you can fix
 your code while you’re working on it rather than potentially after it has been
-shipped to production. We’ve nicknamed this aspect of Rust _fearless_
-_concurrency_. Fearless concurrency allows you to write code that is free of
+shipped to production. We’ve nicknamed this aspect of Rust _fearless
+concurrency_. Fearless concurrency allows you to write code that is free of
 subtle bugs and is easy to refactor without introducing new bugs.
 
 > Note: For simplicity’s sake, we’ll refer to many of the problems as
 > _concurrent_ rather than being more precise by saying _concurrent and/or
-> parallel_. For this chapter, please mentally substitute _concurrent
-> and/or parallel_ whenever we use _concurrent_. In the next chapter, where the
+> parallel_. For this chapter, please mentally substitute _concurrent and/or
+> parallel_ whenever we use _concurrent_. In the next chapter, where the
 > distinction matters more, we’ll be more specific.
 
 Many languages are dogmatic about the solutions they offer for handling
 concurrent problems. For example, Erlang has elegant functionality for
 message-passing concurrency but has only obscure ways to share state between
 threads. Supporting only a subset of possible solutions is a reasonable
-strategy for higher-level languages, because a higher-level language promises
+strategy for higher-level languages because a higher-level language promises
 benefits from giving up some control to gain abstractions. However, lower-level
 languages are expected to provide the solution with the best performance in any
 given situation and have fewer abstractions over the hardware. Therefore, Rust

rustbook-en/nostarch/docx/chapter16.docx

@@ -17,7 +17,7 @@ to problems, such as:
   inconsistent order
 - Deadlocks, in which two threads are waiting for each other, preventing both
   threads from continuing
-- Bugs that happen only in certain situations and are hard to reproduce and fix
+- Bugs that only happen in certain situations and are hard to reproduce and fix
   reliably
 
 Rust attempts to mitigate the negative effects of using threads, but
@@ -26,19 +26,19 @@ a code structure that is different from that in programs running in a single
 thread.
 
 Programming languages implement threads in a few different ways, and many
-operating systems provide an API the language can call for creating new threads.
-The Rust standard library uses a _1:1_ model of thread implementation, whereby a
-program uses one operating system thread per one language thread. There are
-crates that implement other models of threading that make different tradeoffs to
-the 1:1 model. (Rust’s async system, which we will see in the next chapter,
-provides another approach to concurrency as well.)
+operating systems provide an API the programming language can call for creating
+new threads. The Rust standard library uses a _1:1_ model of thread
+implementation, whereby a program uses one operating system thread per one
+language thread. There are crates that implement other models of threading that
+make different trade-offs to the 1:1 model. (Rust’s async system, which we will
+see in the next chapter, provides another approach to concurrency as well.)
 
 ### Creating a New Thread with `spawn`
 
 To create a new thread, we call the `thread::spawn` function and pass it a
 closure (we talked about closures in Chapter 13) containing the code we want to
 run in the new thread. The example in Listing 16-1 prints some text from a main
-thread and other text from a new thread:
+thread and other text from a new thread.
 
 <Listing number="16-1" file-name="src/main.rs" caption="Creating a new thread to print one thing while the main thread prints something else">
 
@@ -88,13 +88,13 @@ the time due to the main thread ending, but because there is no guarantee on
 the order in which threads run, we also can’t guarantee that the spawned thread
 will get to run at all!
 
-We can fix the problem of the spawned thread not running or ending prematurely
-by saving the return value of `thread::spawn` in a variable. The return type of
-`thread::spawn` is `JoinHandle<T>`. A `JoinHandle<T>` is an owned value that,
-when we call the `join` method on it, will wait for its thread to finish.
-Listing 16-2 shows how to use the `JoinHandle<T>` of the thread we created in
-Listing 16-1 and how to call `join` to make sure the spawned thread finishes
-before `main` exits.
+We can fix the problem of the spawned thread not running or of it ending
+prematurely by saving the return value of `thread::spawn` in a variable. The
+return type of `thread::spawn` is `JoinHandle<T>`. A `JoinHandle<T>` is an
+owned value that, when we call the `join` method on it, will wait for its
+thread to finish. Listing 16-2 shows how to use the `JoinHandle<T>` of the
+thread we created in Listing 16-1 and how to call `join` to make sure the
+spawned thread finishes before `main` exits.
 
 <Listing number="16-2" file-name="src/main.rs" caption="Saving a `JoinHandle<T>` from `thread::spawn` to guarantee the thread is run to completion">
 
@@ -172,11 +172,11 @@ threads run at the same time.
 
 ### Using `move` Closures with Threads
 
-We'll often use the `move` keyword with closures passed to `thread::spawn`
+We’ll often use the `move` keyword with closures passed to `thread::spawn`
 because the closure will then take ownership of the values it uses from the
 environment, thus transferring ownership of those values from one thread to
-another. In [“Capturing the Environment With Closures”][capture]<!-- ignore -->
-in Chapter 13, we discussed `move` in the context of closures. Now, we’ll
+another. In [“Capturing References or Moving Ownership”][capture]<!-- ignore
+--> in Chapter 13, we discussed `move` in the context of closures. Now we’ll
 concentrate more on the interaction between `move` and `thread::spawn`.
 
 Notice in Listing 16-1 that the closure we pass to `thread::spawn` takes no
@@ -209,7 +209,7 @@ tell how long the spawned thread will run, so it doesn’t know whether the
 reference to `v` will always be valid.
 
 Listing 16-4 provides a scenario that’s more likely to have a reference to `v`
-that won’t be valid:
+that won’t be valid.
 
 <Listing number="16-4" file-name="src/main.rs" caption="A thread with a closure that attempts to capture a reference to `v` from a main thread that drops `v`">
 
@@ -277,4 +277,4 @@ ownership rules.
 Now that we’ve covered what threads are and the methods supplied by the thread
 API, let’s look at some situations in which we can use threads.
 
-[capture]: ch13-01-closures.html#capturing-the-environment-with-closures
+[capture]: ch13-01-closures.html#capturing-references-or-moving-ownership

rustbook-en/src/ch16-00-concurrency.md

@@ -5,7 +5,7 @@ passing_, where threads or actors communicate by sending each other messages
 containing data. Here’s the idea in a slogan from [the Go language documentation](https://golang.org/doc/effective_go.html#concurrency):
 “Do not communicate by sharing memory; instead, share memory by communicating.”
 
-To accomplish message-sending concurrency, Rust's standard library provides an
+To accomplish message-sending concurrency, Rust’s standard library provides an
 implementation of channels. A _channel_ is a general programming concept by
 which data is sent from one thread to another.
 
@@ -51,13 +51,13 @@ working.
 
 The `mpsc::channel` function returns a tuple, the first element of which is the
 sending end—the transmitter—and the second element of which is the receiving
-end—the receiver. The abbreviations `tx` and `rx` are traditionally used in many
-fields for _transmitter_ and _receiver_, respectively, so we name our variables
-as such to indicate each end. We’re using a `let` statement with a pattern that
-destructures the tuples; we’ll discuss the use of patterns in `let` statements
-and destructuring in Chapter 19. For now, know that using a `let` statement this
-way is a convenient approach to extract the pieces of the tuple returned by
-`mpsc::channel`.
+end—the receiver. The abbreviations `tx` and `rx` are traditionally used in
+many fields for _transmitter_ and _receiver_, respectively, so we name our
+variables as such to indicate each end. We’re using a `let` statement with a
+pattern that destructures the tuples; we’ll discuss the use of patterns in
+`let` statements and destructuring in Chapter 19. For now, know that using a
+`let` statement in this way is a convenient approach to extract the pieces of
+the tuple returned by `mpsc::channel`.
 
 Let’s move the transmitting end into a spawned thread and have it send one
 string so the spawned thread is communicating with the main thread, as shown in
@@ -156,18 +156,19 @@ us an error if we try to compile the code in Listing 16-9:
 {{#include ../listings/ch16-fearless-concurrency/listing-16-09/output.txt}}
 ```
 
-Our concurrency mistake has caused a compile time error. The `send` function
-takes ownership of its parameter, and when the value is moved, the receiver
+Our concurrency mistake has caused a compile-time error. The `send` function
+takes ownership of its parameter, and when the value is moved the receiver
 takes ownership of it. This stops us from accidentally using the value again
 after sending it; the ownership system checks that everything is okay.
 
 ### Sending Multiple Values and Seeing the Receiver Waiting
 
 The code in Listing 16-8 compiled and ran, but it didn’t clearly show us that
-two separate threads were talking to each other over the channel. In Listing
-16-10 we’ve made some modifications that will prove the code in Listing 16-8 is
-running concurrently: the spawned thread will now send multiple messages and
-pause for a second between each message.
+two separate threads were talking to each other over the channel.
+
+In Listing 16-10 we’ve made some modifications that will prove the code in
+Listing 16-8 is running concurrently: the spawned thread will now send multiple
+messages and pause for a second between each message.
 
 <Listing number="16-10" file-name="src/main.rs" caption="Sending multiple messages and pausing between each one">
 

rustbook-en/src/ch16-01-threads.md

@@ -1,14 +1,14 @@
 ## Shared-State Concurrency
 
-Message passing is a fine way to handle concurrency, but it’s not the only
-way. Another method would be for multiple threads to access the same shared
-data. Consider this part of the slogan from the Go language documentation
-again: “Do not communicate by sharing memory.”
+Message passing is a fine way to handle concurrency, but it’s not the only way.
+Another method would be for multiple threads to access the same shared data.
+Consider this part of the slogan from the Go language documentation again: “Do
+not communicate by sharing memory.”
 
 What would communicating by sharing memory look like? In addition, why would
 message-passing enthusiasts caution not to use memory sharing?
 
-In a way, channels in any programming language are similar to single ownership,
+In a way, channels in any programming language are similar to single ownership
 because once you transfer a value down a channel, you should no longer use that
 value. Shared-memory concurrency is like multiple ownership: multiple threads
 can access the same memory location at the same time. As you saw in Chapter 15,
@@ -23,7 +23,7 @@ for shared memory.
 _Mutex_ is an abbreviation for _mutual exclusion_, as in a mutex allows only
 one thread to access some data at any given time. To access the data in a
 mutex, a thread must first signal that it wants access by asking to acquire the
-mutex’s _lock_. The lock is a data structure that is part of the mutex that
+mutex’s lock. The _lock_ is a data structure that is part of the mutex that
 keeps track of who currently has exclusive access to the data. Therefore, the
 mutex is described as _guarding_ the data it holds via the locking system.
 
@@ -76,18 +76,16 @@ that we acquire a lock before using the value in `m`. The type of `m` is
 value. We can’t forget; the type system won’t let us access the inner `i32`
 otherwise.
 
-As you might suspect, `Mutex<T>` is a smart pointer. More accurately, the call
-to `lock` _returns_ a smart pointer called `MutexGuard`, wrapped in a
-`LockResult` that we handled with the call to `unwrap`. The `MutexGuard` smart
-pointer implements `Deref` to point at our inner data; the smart pointer also
-has a `Drop` implementation that releases the lock automatically when a
-`MutexGuard` goes out of scope, which happens at the end of the inner scope. As
-a result, we don’t risk forgetting to release the lock and blocking the mutex
-from being used by other threads, because the lock release happens
-automatically.
+The call to `lock` returns a type called `MutexGuard`, wrapped in a
+`LockResult` that we handled with the call to `unwrap`. The `MutexGuard` type
+implements `Deref` to point at our inner data; the type also has a `Drop`
+implementation that releases the lock automatically when a `MutexGuard` goes
+out of scope, which happens at the end of the inner scope. As a result, we
+don’t risk forgetting to release the lock and blocking the mutex from being
+used by other threads because the lock release happens automatically.
 
 After dropping the lock, we can print the mutex value and see that we were able
-to change the inner `i32` to 6.
+to change the inner `i32` to `6`.
 
 #### Sharing a `Mutex<T>` Between Multiple Threads
 
@@ -125,8 +123,8 @@ We hinted that this example wouldn’t compile. Now let’s find out why!
 ```
 
 The error message states that the `counter` value was moved in the previous
-iteration of the loop. Rust is telling us that we can’t move the ownership
-of lock `counter` into multiple threads. Let’s fix the compiler error with the
+iteration of the loop. Rust is telling us that we can’t move the ownership of
+lock `counter` into multiple threads. Let’s fix the compiler error with the
 multiple-ownership method we discussed in Chapter 15.
 
 #### Multiple Ownership with Multiple Threads
@@ -164,7 +162,7 @@ subtracts from the count when each clone is dropped. But it doesn’t use any
 concurrency primitives to make sure that changes to the count can’t be
 interrupted by another thread. This could lead to wrong counts—subtle bugs that
 could in turn lead to memory leaks or a value being dropped before we’re done
-with it. What we need is a type that is exactly like `Rc<T>` but one that makes
+with it. What we need is a type that is exactly like `Rc<T>`, but that makes
 changes to the reference count in a thread-safe way.
 
 #### Atomic Reference Counting with `Arc<T>`

rustbook-en/src/ch16-02-message-passing.md

@@ -6,30 +6,29 @@
 
 Interestingly, almost every concurrency feature we’ve talked about so far in
 this chapter has been part of the standard library, not the language. Your
-options for handling concurrency are not limited to the language or the standard
-library; you can write your own concurrency features or use those written by
-others.
+options for handling concurrency are not limited to the language or the
+standard library; you can write your own concurrency features or use those
+written by others.
 
 However, among the key concurrency concepts that are embedded in the language
-rather than the standard library are the `std::marker` traits `Send` and
-`Sync`.
+rather than the standard library are the `std::marker` traits `Send` and `Sync`.
 
 ### Allowing Transference of Ownership Between Threads with `Send`
 
 The `Send` marker trait indicates that ownership of values of the type
 implementing `Send` can be transferred between threads. Almost every Rust type
-is `Send`, but there are some exceptions, including `Rc<T>`: this cannot
-implement `Send` because if you cloned an `Rc<T>` value and tried to transfer
-ownership of the clone to another thread, both threads might update the
-reference count at the same time. For this reason, `Rc<T>` is implemented for
-use in single-threaded situations where you don’t want to pay the thread-safe
-performance penalty.
+implements `Send`, but there are some exceptions, including `Rc<T>`: this
+cannot implement `Send` because if you cloned an `Rc<T>` value and tried to
+transfer ownership of the clone to another thread, both threads might update
+the reference count at the same time. For this reason, `Rc<T>` is implemented
+for use in single-threaded situations where you don’t want to pay the
+thread-safe performance penalty.
 
 Therefore, Rust’s type system and trait bounds ensure that you can never
 accidentally send an `Rc<T>` value across threads unsafely. When we tried to do
-this in Listing 16-14, we got the error `the trait Send is not implemented for
-Rc<Mutex<i32>>`. When we switched to `Arc<T>`, which does implement `Send`, the
-code compiled.
+this in Listing 16-14, we got the error `` the trait `Send` is not implemented
+for `Rc<Mutex<i32>>` ``. When we switched to `Arc<T>`, which does implement
+`Send`, the code compiled.
 
 Any type composed entirely of `Send` types is automatically marked as `Send` as
 well. Almost all primitive types are `Send`, aside from raw pointers, which
@@ -39,18 +38,19 @@ we’ll discuss in Chapter 20.
 
 The `Sync` marker trait indicates that it is safe for the type implementing
 `Sync` to be referenced from multiple threads. In other words, any type `T`
-implements  `Sync` if `&T` (an immutable reference to `T`) implements `Send`,
+implements `Sync` if `&T` (an immutable reference to `T`) implements `Send`,
 meaning the reference can be sent safely to another thread. Similar to `Send`,
 primitive types all implement `Sync`, and types composed entirely of types that
 implement `Sync` also implement `Sync`.
 
 The smart pointer `Rc<T>` also doesn’t implement `Sync` for the same reasons
 that it doesn’t implement `Send`. The `RefCell<T>` type (which we talked about
-in Chapter 15) and the family of related `Cell<T>` types don’t implement `Sync`.
-The implementation of borrow checking that `RefCell<T>` does at runtime is not
-thread-safe. The smart pointer `Mutex<T>` implements `Sync` and can be used to
-share access with multiple threads as you saw in [“Sharing a `Mutex<T>` Between
-Multiple Threads”][sharing-a-mutext-between-multiple-threads]<!-- ignore -->.
+in Chapter 15) and the family of related `Cell<T>` types don’t implement
+`Sync`. The implementation of borrow checking that `RefCell<T>` does at runtime
+is not thread-safe. The smart pointer `Mutex<T>` implements `Sync` and can be
+used to share access with multiple threads, as you saw in [“Sharing a
+`Mutex<T>` Between Multiple
+Threads”][sharing-a-mutext-between-multiple-threads]<!-- ignore -->.
 
 ### Implementing `Send` and `Sync` Manually Is Unsafe
 
@@ -71,8 +71,8 @@ uphold them.
 
 This isn’t the last you’ll see of concurrency in this book: the next chapter
 focuses on async programming, and the project in Chapter 21 will use the
-concepts in this chapter in a more realistic situation than the smaller examples
-discussed here.
+concepts in this chapter in a more realistic situation than the smaller
+examples discussed here.
 
 As mentioned earlier, because very little of how Rust handles concurrency is
 part of the language, many concurrency solutions are implemented as crates.