330 lines
19 KiB
HTML
330 lines
19 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<title>Shared-State Concurrency</title>
|
||
</head>
|
||
<body>
|
||
<h2 id="shared-state-concurrency"><a class="header" href="#shared-state-concurrency">Shared-State Concurrency</a></h2>
|
||
<p>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.”</p>
|
||
<p>What would communicating by sharing memory look like? In addition, why would
|
||
message-passing enthusiasts caution not to use memory sharing?</p>
|
||
<p>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,
|
||
where smart pointers made multiple ownership possible, multiple ownership can
|
||
add complexity because these different owners need managing. Rust’s type system
|
||
and ownership rules greatly assist in getting this management correct. For an
|
||
example, let’s look at mutexes, one of the more common concurrency primitives
|
||
for shared memory.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="using-mutexes-to-allow-access-to-data-from-one-thread-at-a-time"></a></p>
|
||
<h3 id="controlling-access-with-mutexes"><a class="header" href="#controlling-access-with-mutexes">Controlling Access with Mutexes</a></h3>
|
||
<p><em>Mutex</em> is an abbreviation for <em>mutual exclusion</em>, 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 <em>lock</em> 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 <em>guarding</em> the data it holds via the locking system.</p>
|
||
<p>Mutexes have a reputation for being difficult to use because you have to
|
||
remember two rules:</p>
|
||
<ol>
|
||
<li>You must attempt to acquire the lock before using the data.</li>
|
||
<li>When you’re done with the data that the mutex guards, you must unlock the
|
||
data so that other threads can acquire the lock.</li>
|
||
</ol>
|
||
<p>For a real-world metaphor for a mutex, imagine a panel discussion at a
|
||
conference with only one microphone. Before a panelist can speak, they have to
|
||
ask or signal that they want to use the microphone. When they get the
|
||
microphone, they can talk for as long as they want to and then hand the
|
||
microphone to the next panelist who requests to speak. If a panelist forgets to
|
||
hand the microphone off when they’re finished with it, no one else is able to
|
||
speak. If management of the shared microphone goes wrong, the panel won’t work
|
||
as planned!</p>
|
||
<p>Management of mutexes can be incredibly tricky to get right, which is why so
|
||
many people are enthusiastic about channels. However, thanks to Rust’s type
|
||
system and ownership rules, you can’t get locking and unlocking wrong.</p>
|
||
<h4 id="the-api-of-mutext"><a class="header" href="#the-api-of-mutext">The API of <code>Mutex<T></code></a></h4>
|
||
<p>As an example of how to use a mutex, let’s start by using a mutex in a
|
||
single-threaded context, as shown in Listing 16-12.</p>
|
||
<figure class="listing" id="listing-16-12">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre class="playground"><code class="language-rust edition2024">use std::sync::Mutex;
|
||
|
||
fn main() {
|
||
let m = Mutex::new(5);
|
||
|
||
{
|
||
let mut num = m.lock().unwrap();
|
||
*num = 6;
|
||
}
|
||
|
||
println!("m = {m:?}");
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-16-12">Listing 16-12</a>: Exploring the API of <code>Mutex<T></code> in a single-threaded context for simplicity</figcaption>
|
||
</figure>
|
||
<p>As with many types, we create a <code>Mutex<T></code> using the associated function <code>new</code>.
|
||
To access the data inside the mutex, we use the <code>lock</code> method to acquire the
|
||
lock. This call will block the current thread so that it can’t do any work
|
||
until it’s our turn to have the lock.</p>
|
||
<p>The call to <code>lock</code> would fail if another thread holding the lock panicked. In
|
||
that case, no one would ever be able to get the lock, so we’ve chosen to
|
||
<code>unwrap</code> and have this thread panic if we’re in that situation.</p>
|
||
<p>After we’ve acquired the lock, we can treat the return value, named <code>num</code> in
|
||
this case, as a mutable reference to the data inside. The type system ensures
|
||
that we acquire a lock before using the value in <code>m</code>. The type of <code>m</code> is
|
||
<code>Mutex<i32></code>, not <code>i32</code>, so we <em>must</em> call <code>lock</code> to be able to use the <code>i32</code>
|
||
value. We can’t forget; the type system won’t let us access the inner <code>i32</code>
|
||
otherwise.</p>
|
||
<p>The call to <code>lock</code> returns a type called <code>MutexGuard</code>, wrapped in a
|
||
<code>LockResult</code> that we handled with the call to <code>unwrap</code>. The <code>MutexGuard</code> type
|
||
implements <code>Deref</code> to point at our inner data; the type also has a <code>Drop</code>
|
||
implementation that releases the lock automatically when a <code>MutexGuard</code> 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.</p>
|
||
<p>After dropping the lock, we can print the mutex value and see that we were able
|
||
to change the inner <code>i32</code> to <code>6</code>.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="sharing-a-mutext-between-multiple-threads"></a></p>
|
||
<h4 id="shared-access-to-mutext"><a class="header" href="#shared-access-to-mutext">Shared Access to <code>Mutex<T></code></a></h4>
|
||
<p>Now let’s try to share a value between multiple threads using <code>Mutex<T></code>. We’ll
|
||
spin up 10 threads and have them each increment a counter value by 1, so the
|
||
counter goes from 0 to 10. The example in Listing 16-13 will have a compiler
|
||
error, and we’ll use that error to learn more about using <code>Mutex<T></code> and how
|
||
Rust helps us use it correctly.</p>
|
||
<figure class="listing" id="listing-16-13">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile">use std::sync::Mutex;
|
||
use std::thread;
|
||
|
||
fn main() {
|
||
let counter = Mutex::new(0);
|
||
let mut handles = vec![];
|
||
|
||
for _ in 0..10 {
|
||
let handle = thread::spawn(move || {
|
||
let mut num = counter.lock().unwrap();
|
||
|
||
*num += 1;
|
||
});
|
||
handles.push(handle);
|
||
}
|
||
|
||
for handle in handles {
|
||
handle.join().unwrap();
|
||
}
|
||
|
||
println!("Result: {}", *counter.lock().unwrap());
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-16-13">Listing 16-13</a>: Ten threads, each incrementing a counter guarded by a <code>Mutex<T></code></figcaption>
|
||
</figure>
|
||
<p>We create a <code>counter</code> variable to hold an <code>i32</code> inside a <code>Mutex<T></code>, as we did
|
||
in Listing 16-12. Next, we create 10 threads by iterating over a range of
|
||
numbers. We use <code>thread::spawn</code> and give all the threads the same closure: one
|
||
that moves the counter into the thread, acquires a lock on the <code>Mutex<T></code> by
|
||
calling the <code>lock</code> method, and then adds 1 to the value in the mutex. When a
|
||
thread finishes running its closure, <code>num</code> will go out of scope and release the
|
||
lock so that another thread can acquire it.</p>
|
||
<p>In the main thread, we collect all the join handles. Then, as we did in Listing
|
||
16-2, we call <code>join</code> on each handle to make sure all the threads finish. At
|
||
that point, the main thread will acquire the lock and print the result of this
|
||
program.</p>
|
||
<p>We hinted that this example wouldn’t compile. Now let’s find out why!</p>
|
||
<pre><code class="language-console">$ cargo run
|
||
Compiling shared-state v0.1.0 (file:///projects/shared-state)
|
||
error[E0382]: borrow of moved value: `counter`
|
||
--> src/main.rs:21:29
|
||
|
|
||
5 | let counter = Mutex::new(0);
|
||
| ------- move occurs because `counter` has type `std::sync::Mutex<i32>`, which does not implement the `Copy` trait
|
||
...
|
||
8 | for _ in 0..10 {
|
||
| -------------- inside of this loop
|
||
9 | let handle = thread::spawn(move || {
|
||
| ------- value moved into closure here, in previous iteration of loop
|
||
...
|
||
21 | println!("Result: {}", *counter.lock().unwrap());
|
||
| ^^^^^^^ value borrowed here after move
|
||
|
|
||
help: consider moving the expression out of the loop so it is only moved once
|
||
|
|
||
8 ~ let mut value = counter.lock();
|
||
9 ~ for _ in 0..10 {
|
||
10 | let handle = thread::spawn(move || {
|
||
11 ~ let mut num = value.unwrap();
|
||
|
|
||
|
||
For more information about this error, try `rustc --explain E0382`.
|
||
error: could not compile `shared-state` (bin "shared-state") due to 1 previous error
|
||
</code></pre>
|
||
<p>The error message states that the <code>counter</code> value was moved in the previous
|
||
iteration of the loop. Rust is telling us that we can’t move the ownership of
|
||
lock <code>counter</code> into multiple threads. Let’s fix the compiler error with the
|
||
multiple-ownership method we discussed in Chapter 15.</p>
|
||
<h4 id="multiple-ownership-with-multiple-threads"><a class="header" href="#multiple-ownership-with-multiple-threads">Multiple Ownership with Multiple Threads</a></h4>
|
||
<p>In Chapter 15, we gave a value to multiple owners by using the smart pointer
|
||
<code>Rc<T></code> to create a reference-counted value. Let’s do the same here and see
|
||
what happens. We’ll wrap the <code>Mutex<T></code> in <code>Rc<T></code> in Listing 16-14 and clone
|
||
the <code>Rc<T></code> before moving ownership to the thread.</p>
|
||
<figure class="listing" id="listing-16-14">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre><code class="language-rust ignore does_not_compile">use std::rc::Rc;
|
||
use std::sync::Mutex;
|
||
use std::thread;
|
||
|
||
fn main() {
|
||
let counter = Rc::new(Mutex::new(0));
|
||
let mut handles = vec![];
|
||
|
||
for _ in 0..10 {
|
||
let counter = Rc::clone(&counter);
|
||
let handle = thread::spawn(move || {
|
||
let mut num = counter.lock().unwrap();
|
||
|
||
*num += 1;
|
||
});
|
||
handles.push(handle);
|
||
}
|
||
|
||
for handle in handles {
|
||
handle.join().unwrap();
|
||
}
|
||
|
||
println!("Result: {}", *counter.lock().unwrap());
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-16-14">Listing 16-14</a>: Attempting to use <code>Rc<T></code> to allow multiple threads to own the <code>Mutex<T></code></figcaption>
|
||
</figure>
|
||
<p>Once again, we compile and get… different errors! The compiler is teaching us
|
||
a lot:</p>
|
||
<pre><code class="language-console">$ cargo run
|
||
Compiling shared-state v0.1.0 (file:///projects/shared-state)
|
||
error[E0277]: `Rc<std::sync::Mutex<i32>>` cannot be sent between threads safely
|
||
--> src/main.rs:11:36
|
||
|
|
||
11 | let handle = thread::spawn(move || {
|
||
| ------------- ^------
|
||
| | |
|
||
| ______________________|_____________within this `{closure@src/main.rs:11:36: 11:43}`
|
||
| | |
|
||
| | required by a bound introduced by this call
|
||
12 | | let mut num = counter.lock().unwrap();
|
||
13 | |
|
||
14 | | *num += 1;
|
||
15 | | });
|
||
| |_________^ `Rc<std::sync::Mutex<i32>>` cannot be sent between threads safely
|
||
|
|
||
= help: within `{closure@src/main.rs:11:36: 11:43}`, the trait `Send` is not implemented for `Rc<std::sync::Mutex<i32>>`
|
||
note: required because it's used within this closure
|
||
--> src/main.rs:11:36
|
||
|
|
||
11 | let handle = thread::spawn(move || {
|
||
| ^^^^^^^
|
||
note: required by a bound in `spawn`
|
||
--> /rustc/1159e78c4747b02ef996e55082b704c09b970588/library/std/src/thread/mod.rs:723:1
|
||
|
||
For more information about this error, try `rustc --explain E0277`.
|
||
error: could not compile `shared-state` (bin "shared-state") due to 1 previous error
|
||
</code></pre>
|
||
<p>Wow, that error message is very wordy! Here’s the important part to focus on:
|
||
<code>`Rc<Mutex<i32>>` cannot be sent between threads safely</code>. The compiler is
|
||
also telling us the reason why: <code>the trait `Send` is not implemented for `Rc<Mutex<i32>>`</code>. We’ll talk about <code>Send</code> in the next section: It’s one of
|
||
the traits that ensures that the types we use with threads are meant for use in
|
||
concurrent situations.</p>
|
||
<p>Unfortunately, <code>Rc<T></code> is not safe to share across threads. When <code>Rc<T></code>
|
||
manages the reference count, it adds to the count for each call to <code>clone</code> and
|
||
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 <code>Rc<T></code>, but that makes
|
||
changes to the reference count in a thread-safe way.</p>
|
||
<h4 id="atomic-reference-counting-with-arct"><a class="header" href="#atomic-reference-counting-with-arct">Atomic Reference Counting with <code>Arc<T></code></a></h4>
|
||
<p>Fortunately, <code>Arc<T></code> <em>is</em> a type like <code>Rc<T></code> that is safe to use in
|
||
concurrent situations. The <em>a</em> stands for <em>atomic</em>, meaning it’s an <em>atomically
|
||
reference-counted</em> type. Atomics are an additional kind of concurrency
|
||
primitive that we won’t cover in detail here: See the standard library
|
||
documentation for <a href="../std/sync/atomic/index.html"><code>std::sync::atomic</code></a><!-- ignore --> for more
|
||
details. At this point, you just need to know that atomics work like primitive
|
||
types but are safe to share across threads.</p>
|
||
<p>You might then wonder why all primitive types aren’t atomic and why standard
|
||
library types aren’t implemented to use <code>Arc<T></code> by default. The reason is that
|
||
thread safety comes with a performance penalty that you only want to pay when
|
||
you really need to. If you’re just performing operations on values within a
|
||
single thread, your code can run faster if it doesn’t have to enforce the
|
||
guarantees atomics provide.</p>
|
||
<p>Let’s return to our example: <code>Arc<T></code> and <code>Rc<T></code> have the same API, so we fix
|
||
our program by changing the <code>use</code> line, the call to <code>new</code>, and the call to
|
||
<code>clone</code>. The code in Listing 16-15 will finally compile and run.</p>
|
||
<figure class="listing" id="listing-16-15">
|
||
<span class="file-name">Filename: src/main.rs</span>
|
||
<pre class="playground"><code class="language-rust edition2024">use std::sync::{Arc, Mutex};
|
||
use std::thread;
|
||
|
||
fn main() {
|
||
let counter = Arc::new(Mutex::new(0));
|
||
let mut handles = vec![];
|
||
|
||
for _ in 0..10 {
|
||
let counter = Arc::clone(&counter);
|
||
let handle = thread::spawn(move || {
|
||
let mut num = counter.lock().unwrap();
|
||
|
||
*num += 1;
|
||
});
|
||
handles.push(handle);
|
||
}
|
||
|
||
for handle in handles {
|
||
handle.join().unwrap();
|
||
}
|
||
|
||
println!("Result: {}", *counter.lock().unwrap());
|
||
}</code></pre>
|
||
<figcaption><a href="#listing-16-15">Listing 16-15</a>: Using an <code>Arc<T></code> to wrap the <code>Mutex<T></code> to be able to share ownership across multiple threads</figcaption>
|
||
</figure>
|
||
<p>This code will print the following:</p>
|
||
<!-- Not extracting output because changes to this output aren't significant;
|
||
the changes are likely to be due to the threads running differently rather than
|
||
changes in the compiler -->
|
||
<pre><code class="language-text">Result: 10
|
||
</code></pre>
|
||
<p>We did it! We counted from 0 to 10, which may not seem very impressive, but it
|
||
did teach us a lot about <code>Mutex<T></code> and thread safety. You could also use this
|
||
program’s structure to do more complicated operations than just incrementing a
|
||
counter. Using this strategy, you can divide a calculation into independent
|
||
parts, split those parts across threads, and then use a <code>Mutex<T></code> to have each
|
||
thread update the final result with its part.</p>
|
||
<p>Note that if you are doing simple numerical operations, there are types simpler
|
||
than <code>Mutex<T></code> types provided by the <a href="../std/sync/atomic/index.html"><code>std::sync::atomic</code> module of the
|
||
standard library</a><!-- ignore -->. These types provide safe, concurrent,
|
||
atomic access to primitive types. We chose to use <code>Mutex<T></code> with a primitive
|
||
type for this example so that we could concentrate on how <code>Mutex<T></code> works.</p>
|
||
<!-- Old headings. Do not remove or links may break. -->
|
||
<p><a id="similarities-between-refcelltrct-and-mutextarct"></a></p>
|
||
<h3 id="comparing-refcelltrct-and-mutextarct"><a class="header" href="#comparing-refcelltrct-and-mutextarct">Comparing <code>RefCell<T></code>/<code>Rc<T></code> and <code>Mutex<T></code>/<code>Arc<T></code></a></h3>
|
||
<p>You might have noticed that <code>counter</code> is immutable but that we could get a
|
||
mutable reference to the value inside it; this means <code>Mutex<T></code> provides
|
||
interior mutability, as the <code>Cell</code> family does. In the same way we used
|
||
<code>RefCell<T></code> in Chapter 15 to allow us to mutate contents inside an <code>Rc<T></code>, we
|
||
use <code>Mutex<T></code> to mutate contents inside an <code>Arc<T></code>.</p>
|
||
<p>Another detail to note is that Rust can’t protect you from all kinds of logic
|
||
errors when you use <code>Mutex<T></code>. Recall from Chapter 15 that using <code>Rc<T></code> came
|
||
with the risk of creating reference cycles, where two <code>Rc<T></code> values refer to
|
||
each other, causing memory leaks. Similarly, <code>Mutex<T></code> comes with the risk of
|
||
creating <em>deadlocks</em>. These occur when an operation needs to lock two resources
|
||
and two threads have each acquired one of the locks, causing them to wait for
|
||
each other forever. If you’re interested in deadlocks, try creating a Rust
|
||
program that has a deadlock; then, research deadlock mitigation strategies for
|
||
mutexes in any language and have a go at implementing them in Rust. The
|
||
standard library API documentation for <code>Mutex<T></code> and <code>MutexGuard</code> offers
|
||
useful information.</p>
|
||
<p>We’ll round out this chapter by talking about the <code>Send</code> and <code>Sync</code> traits and
|
||
how we can use them with custom types.</p>
|
||
</body>
|
||
</html>
|