RustBook/ch16-03-shared-state.html

586 lines
45 KiB
HTML
Raw Normal View History

2020-01-06 20:57:15 +00:00
<!DOCTYPE HTML>
<html lang="en" class="sidebar-visible no-js light">
<head>
<!-- Book generated using mdBook -->
<meta charset="UTF-8">
<title>Shared-State Concurrency - The Rust Programming Language</title>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<meta name="description" content="">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="theme-color" content="#ffffff" />
<link rel="shortcut icon" href="favicon.png">
<link rel="stylesheet" href="css/variables.css">
<link rel="stylesheet" href="css/general.css">
<link rel="stylesheet" href="css/chrome.css">
<link rel="stylesheet" href="css/print.css" media="print">
<!-- Fonts -->
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
<link href="googleFonts/css.css" rel="stylesheet" type="text/css">
<!-- Highlight.js Stylesheets -->
<link rel="stylesheet" href="highlight.css">
<link rel="stylesheet" href="tomorrow-night.css">
<link rel="stylesheet" href="ayu-highlight.css">
<!-- Custom theme stylesheets -->
<link rel="stylesheet" href="ferris.css">
<link rel="stylesheet" href="theme/2018-edition.css">
</head>
<body>
<!-- Provide site root to javascript -->
<script type="text/javascript">
var path_to_root = "";
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "light" : "light";
</script>
<!-- Work around some values being stored in localStorage wrapped in quotes -->
<script type="text/javascript">
try {
var theme = localStorage.getItem('mdbook-theme');
var sidebar = localStorage.getItem('mdbook-sidebar');
if (theme.startsWith('"') && theme.endsWith('"')) {
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
}
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
}
} catch (e) { }
</script>
<!-- Set the theme before any content is loaded, prevents flash -->
<script type="text/javascript">
var theme;
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
if (theme === null || theme === undefined) { theme = default_theme; }
var html = document.querySelector('html');
html.classList.remove('no-js')
html.classList.remove('light')
html.classList.add(theme);
html.classList.add('js');
</script>
<!-- Hide / unhide sidebar before it is displayed -->
<script type="text/javascript">
var html = document.querySelector('html');
var sidebar = 'hidden';
if (document.body.clientWidth >= 1080) {
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
sidebar = sidebar || 'visible';
}
html.classList.remove('sidebar-visible');
html.classList.add("sidebar-" + sidebar);
</script>
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
<div id="sidebar-scrollbox" class="sidebar-scrollbox">
<ol class="chapter"><li class="expanded affix "><a href="title-page.html">The Rust Programming Language</a></li><li class="expanded affix "><a href="foreword.html">Foreword</a></li><li class="expanded affix "><a href="ch00-00-introduction.html">Introduction</a></li><li class="expanded "><a href="ch01-00-getting-started.html"><strong aria-hidden="true">1.</strong> Getting Started</a></li><li><ol class="section"><li class="expanded "><a href="ch01-01-installation.html"><strong aria-hidden="true">1.1.</strong> Installation</a></li><li class="expanded "><a href="ch01-02-hello-world.html"><strong aria-hidden="true">1.2.</strong> Hello, World!</a></li><li class="expanded "><a href="ch01-03-hello-cargo.html"><strong aria-hidden="true">1.3.</strong> Hello, Cargo!</a></li></ol></li><li class="expanded "><a href="ch02-00-guessing-game-tutorial.html"><strong aria-hidden="true">2.</strong> Programming a Guessing Game</a></li><li class="expanded "><a href="ch03-00-common-programming-concepts.html"><strong aria-hidden="true">3.</strong> Common Programming Concepts</a></li><li><ol class="section"><li class="expanded "><a href="ch03-01-variables-and-mutability.html"><strong aria-hidden="true">3.1.</strong> Variables and Mutability</a></li><li class="expanded "><a href="ch03-02-data-types.html"><strong aria-hidden="true">3.2.</strong> Data Types</a></li><li class="expanded "><a href="ch03-03-how-functions-work.html"><strong aria-hidden="true">3.3.</strong> Functions</a></li><li class="expanded "><a href="ch03-04-comments.html"><strong aria-hidden="true">3.4.</strong> Comments</a></li><li class="expanded "><a href="ch03-05-control-flow.html"><strong aria-hidden="true">3.5.</strong> Control Flow</a></li></ol></li><li class="expanded "><a href="ch04-00-understanding-ownership.html"><strong aria-hidden="true">4.</strong> Understanding Ownership</a></li><li><ol class="section"><li class="expanded "><a href="ch04-01-what-is-ownership.html"><strong aria-hidden="true">4.1.</strong> What is Ownership?</a></li><li class="expanded "><a href="ch04-02-references-and-borrowing.html"><strong aria-hidden="true">4.2.</strong> References and Borrowing</a></li><li class="expanded "><a href="ch04-03-slices.html"><strong aria-hidden="true">4.3.</strong> The Slice Type</a></li></ol></li><li class="expanded "><a href="ch05-00-structs.html"><strong aria-hidden="true">5.</strong> Using Structs to Structure Related Data</a></li><li><ol class="section"><li class="expanded "><a href="ch05-01-defining-structs.html"><strong aria-hidden="true">5.1.</strong> Defining and Instantiating Structs</a></li><li class="expanded "><a href="ch05-02-example-structs.html"><strong aria-hidden="true">5.2.</strong> An Example Program Using Structs</a></li><li class="expanded "><a href="ch05-03-method-syntax.html"><strong aria-hidden="true">5.3.</strong> Method Syntax</a></li></ol></li><li class="expanded "><a href="ch06-00-enums.html"><strong aria-hidden="true">6.</strong> Enums and Pattern Matching</a></li><li><ol class="section"><li class="expanded "><a href="ch06-01-defining-an-enum.html"><strong aria-hidden="true">6.1.</strong> Defining an Enum</a></li><li class="expanded "><a href="ch06-02-match.html"><strong aria-hidden="true">6.2.</strong> The match Control Flow Operator</a></li><li class="expanded "><a href="ch06-03-if-let.html"><strong aria-hidden="true">6.3.</strong> Concise Control Flow with if let</a></li></ol></li><li class="expanded "><a href="ch07-00-managing-growing-projects-with-packages-crates-and-modules.html"><strong aria-hidden="true">7.</strong> Managing Growing Projects with Packages, Crates, and Modules</a></li><li><ol class="section"><li class="expanded "><a href="ch07-01-packages-and-crates.html"><strong aria-hidden="true">7.1.</strong> Packages and Crates</a></li><li class="expanded "><a href="ch07-02-defining-modules-to-control-scope-and-privacy.html"><strong aria-hidden="true">7.2.</strong> Defining Modules to Control Scope and Privacy</a></li><li class="expanded "><a href="ch07-03-paths-for-referring-to-an-item-in-the-module-tree.html"><
</div>
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
</nav>
<div id="page-wrapper" class="page-wrapper">
<div class="page">
<div id="menu-bar" class="menu-bar">
<div id="menu-bar-sticky-container">
<div class="left-buttons">
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
<i class="fa fa-bars"></i>
</button>
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
<i class="fa fa-paint-brush"></i>
</button>
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
</ul>
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
<i class="fa fa-search"></i>
</button>
</div>
<h1 class="menu-title">The Rust Programming Language</h1>
<div class="right-buttons">
<a href="print.html" title="Print this book" aria-label="Print this book">
<i id="print-button" class="fa fa-print"></i>
</a>
</div>
</div>
</div>
<div id="search-wrapper" class="hidden">
<form id="searchbar-outer" class="searchbar-outer">
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
</form>
<div id="searchresults-outer" class="searchresults-outer hidden">
<div id="searchresults-header" class="searchresults-header"></div>
<ul id="searchresults">
</ul>
</div>
</div>
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
<script type="text/javascript">
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
});
</script>
<div id="content" class="content">
<main>
<h2><a class="header" href="#shared-state-concurrency" id="shared-state-concurrency">Shared-State Concurrency</a></h2>
<p>Message passing is a fine way of handling concurrency, but its not the only
one. 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 not use it and do the opposite instead?</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. Rusts type system
and ownership rules greatly assist in getting this management correct. For an
example, lets look at mutexes, one of the more common concurrency primitives
for shared memory.</p>
<h3><a class="header" href="#using-mutexes-to-allow-access-to-data-from-one-thread-at-a-time" id="using-mutexes-to-allow-access-to-data-from-one-thread-at-a-time">Using Mutexes to Allow Access to Data from One Thread at a Time</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
mutexs <em>lock</em>. 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 <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>
<ul>
<li>You must attempt to acquire the lock before using the data.</li>
<li>When youre done with the data that the mutex guards, you must unlock the
data so other threads can acquire the lock.</li>
</ul>
<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 theyre finished with it, no one else is able to
speak. If management of the shared microphone goes wrong, the panel wont 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 Rusts type
system and ownership rules, you cant get locking and unlocking wrong.</p>
<h4><a class="header" href="#the-api-of-mutext" id="the-api-of-mutext">The API of <code>Mutex&lt;T&gt;</code></a></h4>
<p>As an example of how to use a mutex, lets start by using a mutex in a
single-threaded context, as shown in Listing 16-12:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust">use std::sync::Mutex;
fn main() {
let m = Mutex::new(5);
{
let mut num = m.lock().unwrap();
*num = 6;
}
println!(&quot;m = {:?}&quot;, m);
}
</code></pre></pre>
<p><span class="caption">Listing 16-12: Exploring the API of <code>Mutex&lt;T&gt;</code> in a
single-threaded context for simplicity</span></p>
<p>As with many types, we create a <code>Mutex&lt;T&gt;</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 it cant do any work until
its 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 weve chosen to
<code>unwrap</code> and have this thread panic if were in that situation.</p>
<p>After weve 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>: <code>Mutex&lt;i32&gt;</code> is not an
<code>i32</code>, so we <em>must</em> acquire the lock to be able to use the <code>i32</code> value. We
cant forget; the type system wont let us access the inner <code>i32</code> otherwise.</p>
<p>As you might suspect, <code>Mutex&lt;T&gt;</code> is a smart pointer. More accurately, the call
to <code>lock</code> <em>returns</em> a smart pointer called <code>MutexGuard</code>, wrapped in a
<code>LockResult</code> that we handled with the call to <code>unwrap</code>. The <code>MutexGuard</code> smart
pointer implements <code>Deref</code> to point at our inner data; the smart pointer 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 in
Listing 16-12. As a result, we dont 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 6.</p>
<h4><a class="header" href="#sharing-a-mutext-between-multiple-threads" id="sharing-a-mutext-between-multiple-threads">Sharing a <code>Mutex&lt;T&gt;</code> Between Multiple Threads</a></h4>
<p>Now, lets try to share a value between multiple threads using <code>Mutex&lt;T&gt;</code>.
Well spin up 10 threads and have them each increment a counter value by 1, so
the counter goes from 0 to 10. Note that the next few examples will have
compiler errors, and well use those errors to learn more about using
<code>Mutex&lt;T&gt;</code> and how Rust helps us use it correctly. Listing 16-13 has our
starting example:</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<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!(&quot;Result: {}&quot;, *counter.lock().unwrap());
}
</code></pre>
<p><span class="caption">Listing 16-13: Ten threads each increment a counter
guarded by a <code>Mutex&lt;T&gt;</code></span></p>
<p>We create a <code>counter</code> variable to hold an <code>i32</code> inside a <code>Mutex&lt;T&gt;</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&lt;T&gt;</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 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 wouldnt compile. Now lets find out why!</p>
<pre><code class="language-text">error[E0382]: capture of moved value: `counter`
--&gt; src/main.rs:10:27
|
9 | let handle = thread::spawn(move || {
| ------- value moved (into closure) here
10 | let mut num = counter.lock().unwrap();
| ^^^^^^^ value captured here after move
|
= note: move occurs because `counter` has type `std::sync::Mutex&lt;i32&gt;`,
which does not implement the `Copy` trait
error[E0382]: use of moved value: `counter`
--&gt; src/main.rs:21:29
|
9 | let handle = thread::spawn(move || {
| ------- value moved (into closure) here
...
21 | println!(&quot;Result: {}&quot;, *counter.lock().unwrap());
| ^^^^^^^ value used here after move
|
= note: move occurs because `counter` has type `std::sync::Mutex&lt;i32&gt;`,
which does not implement the `Copy` trait
error: aborting due to 2 previous errors
</code></pre>
<p>The error message states that the <code>counter</code> value is moved into the closure and
then captured when we call <code>lock</code>. That description sounds like what we wanted,
but its not allowed!</p>
<p>Lets figure this out by simplifying the program. Instead of making 10 threads
in a <code>for</code> loop, lets just make two threads without a loop and see what
happens. Replace the first <code>for</code> loop in Listing 16-13 with this code instead:</p>
<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![];
let handle = thread::spawn(move || {
let mut num = counter.lock().unwrap();
*num += 1;
});
handles.push(handle);
let handle2 = thread::spawn(move || {
let mut num2 = counter.lock().unwrap();
*num2 += 1;
});
handles.push(handle2);
for handle in handles {
handle.join().unwrap();
}
println!(&quot;Result: {}&quot;, *counter.lock().unwrap());
}
</code></pre>
<p>We make two threads and change the variable names used with the second thread
to <code>handle2</code> and <code>num2</code>. When we run the code this time, compiling gives us the
following:</p>
<pre><code class="language-text">error[E0382]: capture of moved value: `counter`
--&gt; src/main.rs:16:24
|
8 | let handle = thread::spawn(move || {
| ------- value moved (into closure) here
...
16 | let mut num2 = counter.lock().unwrap();
| ^^^^^^^ value captured here after move
|
= note: move occurs because `counter` has type `std::sync::Mutex&lt;i32&gt;`,
which does not implement the `Copy` trait
error[E0382]: use of moved value: `counter`
--&gt; src/main.rs:26:29
|
8 | let handle = thread::spawn(move || {
| ------- value moved (into closure) here
...
26 | println!(&quot;Result: {}&quot;, *counter.lock().unwrap());
| ^^^^^^^ value used here after move
|
= note: move occurs because `counter` has type `std::sync::Mutex&lt;i32&gt;`,
which does not implement the `Copy` trait
error: aborting due to 2 previous errors
</code></pre>
<p>Aha! The first error message indicates that <code>counter</code> is moved into the closure
for the thread associated with <code>handle</code>. That move is preventing us from
capturing <code>counter</code> when we try to call <code>lock</code> on it and store the result in
<code>num2</code> in the second thread! So Rust is telling us that we cant move ownership
of <code>counter</code> into multiple threads. This was hard to see earlier because our
threads were in a loop, and Rust cant point to different threads in different
iterations of the loop. Lets fix the compiler error with a multiple-ownership
method we discussed in Chapter 15.</p>
<h4><a class="header" href="#multiple-ownership-with-multiple-threads" id="multiple-ownership-with-multiple-threads">Multiple Ownership with Multiple Threads</a></h4>
<p>In Chapter 15, we gave a value multiple owners by using the smart pointer
<code>Rc&lt;T&gt;</code> to create a reference counted value. Lets do the same here and see
what happens. Well wrap the <code>Mutex&lt;T&gt;</code> in <code>Rc&lt;T&gt;</code> in Listing 16-14 and clone
the <code>Rc&lt;T&gt;</code> before moving ownership to the thread. Now that weve seen the
errors, well also switch back to using the <code>for</code> loop, and well keep the
<code>move</code> keyword with the closure.</p>
<p><span class="filename">Filename: src/main.rs</span></p>
<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(&amp;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!(&quot;Result: {}&quot;, *counter.lock().unwrap());
}
</code></pre>
<p><span class="caption">Listing 16-14: Attempting to use <code>Rc&lt;T&gt;</code> to allow
multiple threads to own the <code>Mutex&lt;T&gt;</code></span></p>
<p>Once again, we compile and get... different errors! The compiler is teaching us
a lot.</p>
<pre><code class="language-text">error[E0277]: the trait bound `std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;:
std::marker::Send` is not satisfied in `[closure@src/main.rs:11:36:
15:10 counter:std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;]`
--&gt; src/main.rs:11:22
|
11 | let handle = thread::spawn(move || {
| ^^^^^^^^^^^^^ `std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;`
cannot be sent between threads safely
|
= help: within `[closure@src/main.rs:11:36: 15:10
counter:std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;]`, the trait `std::marker::Send` is
not implemented for `std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;`
= note: required because it appears within the type
`[closure@src/main.rs:11:36: 15:10 counter:std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;]`
= note: required by `std::thread::spawn`
</code></pre>
<p>Wow, that error message is very wordy! Here are some important parts to focus
on: the first inline error says <code>`std::rc::Rc&lt;std::sync::Mutex&lt;i32&gt;&gt;` cannot be sent between threads safely</code>. The reason for this is in the next important
part to focus on, the error message. The distilled error message says <code>the trait bound `Send` is not satisfied</code>. Well talk about <code>Send</code> in the next
section: its one of the traits that ensures the types we use with threads are
meant for use in concurrent situations.</p>
<p>Unfortunately, <code>Rc&lt;T&gt;</code> is not safe to share across threads. When <code>Rc&lt;T&gt;</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 doesnt use any
concurrency primitives to make sure that changes to the count cant 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 were done
with it. What we need is a type exactly like <code>Rc&lt;T&gt;</code> but one that makes changes
to the reference count in a thread-safe way.</p>
<h4><a class="header" href="#atomic-reference-counting-with-arct" id="atomic-reference-counting-with-arct">Atomic Reference Counting with <code>Arc&lt;T&gt;</code></a></h4>
<p>Fortunately, <code>Arc&lt;T&gt;</code> <em>is</em> a type like <code>Rc&lt;T&gt;</code> that is safe to use in
concurrent situations. The <em>a</em> stands for <em>atomic</em>, meaning its an <em>atomically
reference counted</em> type. Atomics are an additional kind of concurrency
primitive that we wont cover in detail here: see the standard library
documentation for <code>std::sync::atomic</code> 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 arent atomic and why standard
library types arent implemented to use <code>Arc&lt;T&gt;</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 youre just performing operations on values within a
single thread, your code can run faster if it doesnt have to enforce the
guarantees atomics provide.</p>
<p>Lets return to our example: <code>Arc&lt;T&gt;</code> and <code>Rc&lt;T&gt;</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>
<p><span class="filename">Filename: src/main.rs</span></p>
<pre><pre class="playpen"><code class="language-rust">use std::sync::{Mutex, Arc};
use std::thread;
fn main() {
let counter = Arc::new(Mutex::new(0));
let mut handles = vec![];
for _ in 0..10 {
let counter = Arc::clone(&amp;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!(&quot;Result: {}&quot;, *counter.lock().unwrap());
}
</code></pre></pre>
<p><span class="caption">Listing 16-15: Using an <code>Arc&lt;T&gt;</code> to wrap the <code>Mutex&lt;T&gt;</code>
to be able to share ownership across multiple threads</span></p>
<p>This code will print the following:</p>
<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&lt;T&gt;</code> and thread safety. You could also use this
programs 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&lt;T&gt;</code> to have each
thread update the final result with its part.</p>
<h3><a class="header" href="#similarities-between-refcelltrct-and-mutextarct" id="similarities-between-refcelltrct-and-mutextarct">Similarities Between <code>RefCell&lt;T&gt;</code>/<code>Rc&lt;T&gt;</code> and <code>Mutex&lt;T&gt;</code>/<code>Arc&lt;T&gt;</code></a></h3>
<p>You might have noticed that <code>counter</code> is immutable but we could get a mutable
reference to the value inside it; this means <code>Mutex&lt;T&gt;</code> provides interior
mutability, as the <code>Cell</code> family does. In the same way we used <code>RefCell&lt;T&gt;</code> in
Chapter 15 to allow us to mutate contents inside an <code>Rc&lt;T&gt;</code>, we use <code>Mutex&lt;T&gt;</code>
to mutate contents inside an <code>Arc&lt;T&gt;</code>.</p>
<p>Another detail to note is that Rust cant protect you from all kinds of logic
errors when you use <code>Mutex&lt;T&gt;</code>. Recall in Chapter 15 that using <code>Rc&lt;T&gt;</code> came
with the risk of creating reference cycles, where two <code>Rc&lt;T&gt;</code> values refer to
each other, causing memory leaks. Similarly, <code>Mutex&lt;T&gt;</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 youre 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&lt;T&gt;</code> and <code>MutexGuard</code> offers
useful information.</p>
<p>Well 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>
</main>
<nav class="nav-wrapper" aria-label="Page navigation">
<!-- Mobile navigation buttons -->
<a rel="prev" href="ch16-02-message-passing.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a rel="next" href="ch16-04-extensible-concurrency-sync-and-send.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
<div style="clear: both"></div>
</nav>
</div>
</div>
<nav class="nav-wide-wrapper" aria-label="Page navigation">
<a href="ch16-02-message-passing.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
<i class="fa fa-angle-left"></i>
</a>
<a href="ch16-04-extensible-concurrency-sync-and-send.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
<i class="fa fa-angle-right"></i>
</a>
</nav>
</div>
<script type="text/javascript">
window.playpen_copyable = true;
</script>
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
<script src="book.js" type="text/javascript" charset="utf-8"></script>
<!-- Custom JS scripts -->
<script type="text/javascript" src="ferris.js"></script>
</body>
</html>