22.3Shared state: Mutex and Arc

Last updated June 13, 2026

Channels (lesson 22.2) move data so it's never shared. But some problems are inherently about shared data: a counter many threads increment, a cache they all read and update, one configuration they all consult. For these you need multiple threads touching the same memory, and that's where concurrency is genuinely hard. Rust makes it safe with two cooperating tools: a Mutex to control access, and an Arc to share ownership. Neither alone is enough; together they're the standard pattern.

Mutex: one thread at a time

A mutex (short for "mutual exclusion") is a lock around a piece of data. The rule it enforces: to touch the data, a thread must first acquire the lock, and only one thread can hold the lock at a time. Everyone else waits. This guarantees that at any instant exactly one thread is accessing the data, no two threads ever read-and-write it at once, which is precisely what a data race is.

In Rust, Mutex<T> wraps the data it protects, you can't get at the value without going through the lock. Here it is single-threaded, just to see the API:

use std::sync::Mutex;

fn main() {
    let m = Mutex::new(5);

    {
        let mut num = m.lock().unwrap();
        *num = 6;
    }   // lock released here when `num` goes out of scope

    println!("{m:?}");
}

Mutex { data: 6, poisoned: false, .. }

m.lock() acquires the lock, blocking until it's available, and returns a guard (a MutexGuard) that you use like a mutable reference to the inner value: *num = 6 changes the data through it. The lock() returns a Result (it fails if another thread panicked while holding the lock, "poisoning" it), so we unwrap. The crucial part is the release: when the guard num goes out of scope, the lock is automatically released by its Drop (chapter 21, RAII at work). You never manually unlock; scope does it, which means you can't forget to unlock, the single most common mutex bug in other languages.

Notice that Mutex gave us mutation (*num = 6) even though m isn't mut. That's interior mutability (lesson 21.6) again: Mutex is the thread-safe RefCell, enforcing the borrow rules with a runtime lock instead of a runtime counter.

Sharing the mutex across threads: enter Arc

Now the real goal: many threads sharing one mutex. They all need to own the mutex (it has to outlive each of them), which is shared ownership, the job of Rc from chapter 21. But Rc is single-threaded only (its count isn't safe to update concurrently), so the compiler won't let it cross a thread boundary. Its thread-safe sibling is Arc<T>: "atomically reference counted." Same shared-ownership idea as Rc, but with a counter that's safe to update from multiple threads at once.

The canonical example, ten threads each incrementing a shared counter:

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());
}

result: 10

Read the shape, because it's the pattern you'll reuse constantly. Arc::new(Mutex::new(0)) wraps the counter in a mutex (for safe access) inside an Arc (for shared ownership). The loop spawns ten threads; each gets its own Arc::clone (a cheap new handle to the same counter, lesson 21.5) and moves it into the thread. Inside, each thread locks, increments, and the lock releases at the end of the closure. We collect the handles and join them all so main waits for every thread. The result is reliably 10: the mutex guarantees the ten increments don't trample each other.

Why two types instead of one

It's reasonable to ask why Rust splits this into Arc and Mutex rather than one combined type. Because they solve independent problems. Arc answers "who owns this?", many threads, freed when the last releases it, but Arc alone gives only shared read access, just like Rc. Mutex answers "how do we mutate it safely?", lock, change, unlock, but Mutex alone is a single value with no way to share it among threads. You need both because the problem has both halves: shared ownership and safe mutation. Keeping them separate also means you only pay for what you use, shared immutable data needs just Arc, and a mutex owned by one thread needs no Arc.

Quiz time

Question #1

What does a Mutex guarantee, and how is the lock released?

Question #2

Why do you need Arc and Mutex together to share mutable data across threads? What does each provide?

Question #3

Why is Arc used here instead of Rc?

You can now share data across threads safely, but what makes a type safe to share at all? The compiler decides this automatically using two marker traits. The next lesson (22.4) introduces Send and Sync, the quiet machinery that makes "fearless" a compile-time guarantee rather than a hope.