Learning Rust's Arc and Mutex: Sharing Mutable State Between Threads

Introduction

After learning how to spawn threads and use thread::scope to borrow data, I hit a wall: what if I need to modify shared data from multiple threads?

The previous post covered how to read data across threads using scoped borrowing. This post tackles the much harder problem: sharing mutable state. This is where most concurrency bugs live. It’s also where Rust’s design shines — the compiler forces you to think about synchronization before anything breaks.

If you haven’t read Learning Rust Threads, start there. This post builds directly on those concepts.

The Problem: Modifying Shared Data

Imagine you have a counter and you want multiple threads to increment it:

1
let mut counter = 0;
2

3
thread::spawn(move || {
4
    counter += 1;  // Error: cannot move mutable local variable
5
});
6

7
thread::spawn(move || {
8
    counter += 1;  // Same error
9
});

This doesn’t compile. Why? The first thread moves counter, so the second thread can’t move the same variable. Even if it could, the borrow checker would reject it: two threads trying to mutate the same data with no synchronization is a data race waiting to happen.

In other languages, you might reach for a lock. Rust forces you to reach for a lock because the compiler won’t let you do it any other way.

Meet the Players: Arc, Mutex, and lock()

Solving this requires two types working together:

• Arc<T> — Atomic Reference Counting. A thread-safe pointer that lets multiple threads own the same value.
• Mutex<T> — A mutual exclusion lock. Only one thread can access the protected data at a time.

Together, Arc<Mutex<T>> is the workhorse pattern for sharing mutable data in Rust.

Building the Pattern: Step by Step

Let’s build a concurrent counter from scratch, understanding each piece.

Step 1: Protect Data with Mutex<T>

First, wrap your data in a Mutex:

1
use std::sync::Mutex;
2

3
let counter = Mutex::new(0);

A Mutex ensures only one thread accesses the protected data at a time. To read or modify the data, you must call .lock():

1
let counter = Mutex::new(0);
2
let mut count = counter.lock().unwrap();
3
*count += 1;  // Modify the protected data
4
// count is dropped here, releasing the lock

.lock() returns a Result. If the lock is held by another thread, it blocks until available. .unwrap() panics if the lock was poisoned (the thread that held it panicked). In production, handle this more carefully.

Step 2: Enable Sharing Across Threads with Arc<T>

A Mutex<T> by itself can’t be shared across threads because move closures transfer ownership. You need multiple threads to own the same Mutex. This is what Arc does:

1
use std::sync::{Arc, Mutex};
2
use std::thread;
3

4
let counter = Arc::new(Mutex::new(0));  // Wrapped twice!
5

6
let counter_clone = Arc::clone(&counter);  // Share ownership
7
thread::spawn(move || {
8
    let mut count = counter_clone.lock().unwrap();
9
    *count += 1;
10
});
11

12
// Original counter is still valid
13
let count = counter.lock().unwrap();
14
println!("Count: {}", *count);

Arc::clone(&counter) creates a new reference to the same data (not a deep copy). Multiple threads can own this reference independently.

Step 3: Full Pattern — Multiple Threads Incrementing

Here’s the complete pattern:

1
use std::sync::{Arc, Mutex};
2
use std::thread;
3

4
let counter = Arc::new(Mutex::new(0));
5
let mut handles = Vec::new();
6

7
for _ in 0..5 {
8
    let counter = Arc::clone(&counter);  // Share ownership
9
    let handle = thread::spawn(move || {
10
        for _ in 0..10 {
11
            let mut count = counter.lock().unwrap();
12
            *count += 1;
13
            // Lock is released when `count` is dropped
14
        }
15
    });
16
    handles.push(handle);
17
}
18

19
// Wait for all threads
20
for handle in handles {
21
    handle.join().unwrap();
22
}
23

24
// Get final value
25
let final_count = *counter.lock().unwrap();
26
println!("Final count: {}", final_count);  // Final count: 50

Let’s trace through the flow:

1. Arc::new(Mutex::new(0)) creates a thread-safe counter, initially 0.
2. In each loop iteration, Arc::clone(&counter) creates a new reference to the same counter.
3. thread::spawn(move || { ... }) moves that reference into the closure. Each thread owns a clone of the Arc, not the Mutex itself.
4. Inside the thread, .lock().unwrap() acquires the lock, giving us mutable access.
5. *count += 1 modifies the protected data.
6. When count is dropped (at the end of the loop or scope), the lock is released.
7. .join() waits for all threads to finish.
8. The final counter.lock().unwrap() accesses the shared counter from the main thread.

Understanding the Two Layers

Understanding why you need both Arc and Mutex unlocks a lot of Rust thinking.

Mutex<T> — Synchronization

Mutex<T> ensures mutual exclusion. Only one thread accesses the data at a time. Without it:

1
let counter = Arc::new(0);  // Just Arc, no Mutex
2
// Two threads both read counter, both increment, both write back
3
// Result: 1 instead of 2 (lost update, data race)

A Mutex prevents this by forcing serialized access.

Arc<T> — Ownership

Arc<T> enables shared ownership. Without it:

1
let counter = Mutex::new(0);
2
thread::spawn(move || {
3
    counter.lock().unwrap().  // error: `counter` was moved
4
});
5
thread::spawn(move || {
6
    counter.lock().unwrap();  // error: `counter` was already moved
7
});

You can’t move the same value to two threads. Arc lets multiple threads own pointers to the same value.

Common Pattern: Collect Results from Threads

Instead of modifying a counter, what if you want threads to collect results?

1
use std::sync::{Arc, Mutex};
2
use std::thread;
3

4
let results = Arc::new(Mutex::new(Vec::new()));
5
let mut handles = Vec::new();
6

7
for i in 0..5 {
8
    let results = Arc::clone(&results);
9
    let handle = thread::spawn(move || {
10
        let computation = i * 2;  // Simulate some work
11
        let mut vec = results.lock().unwrap();
12
        vec.push(computation);
13
    });
14
    handles.push(handle);
15
}
16

17
for handle in handles {
18
    handle.join().unwrap();
19
}
20

21
let mut final_results = results.lock().unwrap();
22
final_results.sort();
23
println!("Results: {:?}", *final_results);  // Results: [0, 2, 4, 6, 8]

The pattern is identical: Arc<Mutex<T>> where T can be any type — a counter, a vector, a struct, anything.

1
let results = Arc::new(Mutex::new(Vec::new()));
2

3
// ... threads push results ...
4

5
let mut vec = results.lock().unwrap();
6
vec.sort();  // Process while holding lock
7
// Lock is dropped here
8
println!("Sorted: {:?}", *vec);  // vec is no longer accessible

1
let vec = results.lock().unwrap().clone();  // Clone, then drop lock
2
vec.sort();  // Process without holding lock

Gotchas and Debugging

Gotcha 1: Forgetting .clone() (or Arc::clone())

This is the most common mistake:

1
let counter = Arc::new(Mutex::new(0));
2

3
for _ in 0..3 {
4
    thread::spawn(move || {  // OOPS: moves counter once
5
        counter.lock().unwrap();  // But which thread gets it?
6
    });
7
}

The first thread moves counter, and the remaining threads can’t access it. You must clone for each thread:

1
for _ in 0..3 {
2
    let counter = Arc::clone(&counter);  // Clone for each iteration
3
    thread::spawn(move || {
4
        counter.lock().unwrap();
5
    });
6
}

Gotcha 2: Lock Poisoning

If a thread panics while holding a lock, the Mutex becomes “poisoned”. Future .lock() calls return Err:

1
let counter = Arc::new(Mutex::new(0));
2
let counter_clone = Arc::clone(&counter);
3

4
thread::spawn(move || {
5
    let mut count = counter_clone.lock().unwrap();
6
    panic!("Oops!");
7
    // Lock is never released — poisoned
8
});
9

10
std::thread::sleep(std::time::Duration::from_millis(10));
11

12
// This will panic when unwrapped
13
counter.lock().unwrap();  // error: poisoned lock

In production, handle poisoned locks:

1
match counter.lock() {
2
    Ok(mut count) => { *count += 1; },
3
    Err(e) => {
4
        eprintln!("Lock poisoned: {}", e);
5
        // Either panic or recover
6
    }
7
}

Or use .lock().unwrap_or_else() to recover a poisoned lock:

1
let mut count = counter.lock().unwrap_or_else(|e| e.into_inner());
2
*count += 1;

Gotcha 3: Deadlocks

Deadlocks are rare with a single Mutex, but possible with multiple:

1
let a = Arc::new(Mutex::new(0));
2
let b = Arc::new(Mutex::new(0));
3

4
// Thread 1: locks a, then tries to lock b
5
let a1 = Arc::clone(&a);
6
let b1 = Arc::clone(&b);
7
thread::spawn(move || {
8
    let _x = a1.lock().unwrap();
9
    std::thread::sleep(std::time::Duration::from_millis(1));
10
    let _y = b1.lock().unwrap();  // Waiting for b
11
});
12

13
// Thread 2: locks b, then tries to lock a
14
let a2 = Arc::clone(&a);
15
let b2 = Arc::clone(&b);
16
thread::spawn(move || {
17
    let _y = b2.lock().unwrap();
18
    std::thread::sleep(std::time::Duration::from_millis(1));
19
    let _x = a2.lock().unwrap();  // Waiting for a
20
});

Thread 1 holds a and waits for b. Thread 2 holds b and waits for a. Deadlock.

The rule: Always acquire locks in the same order. If this is complex, redesign to use fewer locks or use higher-level abstractions.

When to Use Arc<Mutex<T>>

Not every shared value needs Arc<Mutex<T>>. Here’s a decision tree:

The Full Picture: Send and Sync Again

Remember Send and Sync from the previous post? They’re relevant here.

• Mutex<T> is Sync (safe to share references) because the mutex ensures exclusive access.
• Arc<T> is Send and Sync if T is Send and Sync.
• Together, Arc<Mutex<T>> is Send and Sync as long as T is Send.

This is why the compiler allows you to move Arc<Mutex<T>> to another thread and share it — the types implement the required traits.

1
let counter: Arc<Mutex<usize>> = Arc::new(Mutex::new(0));
2
// Arc<Mutex<usize>> is Send and Sync because:
3
// - usize is Send
4
// - Mutex<usize> is Sync
5
// - Arc wraps them safely
6

7
thread::spawn(move || {
8
    // Moving Arc<Mutex<usize>> across threads is safe
9
    counter.lock().unwrap();
10
});

Practical Example: Word Counter

Let’s build something more realistic — counting word frequencies from multiple text chunks processed in parallel:

1
use std::sync::{Arc, Mutex};
2
use std::thread;
3
use std::collections::HashMap;
4

5
fn count_words_parallel(texts: Vec<&str>) -> HashMap<String, usize> {
6
    let word_counts = Arc::new(Mutex::new(HashMap::new()));
7
    let mut handles = Vec::new();
8

9
    for text in texts {
10
        let word_counts = Arc::clone(&word_counts);
11
        let handle = thread::spawn(move || {
12
            for word in text.split_whitespace() {
13
                let mut counts = word_counts.lock().unwrap();
14
                *counts.entry(word.to_string())
15
                    .or_insert(0) += 1;
16
            }
17
        });
18
        handles.push(handle);
19
    }
20

21
    for handle in handles {
22
        handle.join().unwrap();
23
    }
24

25
    // Extract and return the final counts
26
    Arc::try_unwrap(word_counts)
27
        .unwrap_or_else(|arc| (*arc.lock().unwrap()).clone())
28
        .into_inner()
29
        .unwrap()
30
}
31

32
let texts = vec![
33
    "hello world hello rust",
34
    "rust is great",
35
    "hello rust world",
36
];
37

38
let counts = count_words_parallel(texts);
39
println!("Word counts: {:?}", counts);

Here, multiple threads safely modify a shared HashMap by locking, incrementing, and releasing the lock.

From Theory to Practice

The pattern Arc<Mutex<T>> appears everywhere in Rust concurrent code:

• Caches: Shared, mutable cache accessed by worker threads.
• Counters: Metrics updated by multiple threads.
• Queues: Collecting results from parallel jobs.
• Configuration: Shared state that changes over time (though often read-heavy, suitable for Arc<RwLock<T>>).

Once you internalize this pattern, a huge class of concurrency problems becomes manageable.

References

• The Rust Book — Chapter 16: Sharing State
• Rust Standard Library — Arc<T>
• Rust Standard Library — Mutex<T>
• Rust Concurrency Patterns — Locking
• Rustonomicon — Concurrency