Shared state: Arc, Mutex, Send and Sync

When messages are not enough

Sometimes several threads must update the same thing: a counter of website visits, a cache of exchange rates, a shared inventory. For this you need shared state with synchronisation, meaning a rule that only one thread changes the data at a time.

Mutex: one thread at a time

A Mutex (mutual exclusion) protects data so only one thread can access it at a time. To use the data, a thread calls lock(). If another thread holds the lock, the caller waits. lock() returns a MutexGuard, a smart pointer to the data. When the guard is dropped, the lock is released automatically, so you cannot forget to unlock.

use std::sync::Mutex;

let stock = Mutex::new(10);
{
    let mut s = stock.lock().unwrap();   // lock; s is a MutexGuard<i32>
    *s -= 3;
}                                        // guard dropped: unlocked here
println!("{:?}", stock.lock().unwrap()); // 7

Arc: sharing ownership across threads

Each thread needs to own a handle to the Mutex. Rc cannot be used, because its counter is not thread-safe. Arc<T> (atomically reference counted) is the same idea as Rc, but it updates the count with atomic CPU instructions that are safe across threads. They cost slightly more, which is why Rc also exists.

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let visits = Arc::new(Mutex::new(0));
    let mut handles = vec![];

    for _ in 0..8 {
        let visits = Arc::clone(&visits);
        handles.push(thread::spawn(move || {
            for _ in 0..1000 {
                *visits.lock().unwrap() += 1;
            }
        }));
    }
    for h in handles {
        h.join().unwrap();
    }
    println!("{}", *visits.lock().unwrap());   // always 8000
}

thread 1 --Arc--+
thread 2 --Arc--+--> [ count | Mutex { locked?, data: 0 } ]   (heap)
   ...           |
thread 8 --Arc--+

Send and Sync in plain words

• Send: a value of this type can be moved to another thread. Most types are Send. Rc is not, because two threads could update its counter at once.
• Sync: a &T (a shared reference) can be used from several threads at once. Mutex<T> is Sync (when T is Send), which is why Arc<Mutex<T>> works. RefCell is not Sync.

You almost never implement these by hand; the compiler works them out from a type's fields. Their job is to make thread mistakes compile errors: try to move an Rc into thread::spawn and you get "Rc<...> cannot be sent between threads safely".

Deadlocks and other choices

A deadlock happens when thread A holds lock 1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1. Both wait forever. Rust does not prevent deadlocks. Avoid them by keeping locks short, never calling unknown code while holding a lock, and always taking several locks in the same order.

Common mistakes

• Using Rc instead of Arc with threads: compile error "cannot be sent between threads safely".
• Holding a lock guard for a long time (for example across a slow file write). Copy the data out, drop the guard, then do slow work.
• Locking the same Mutex twice in one thread: the second lock waits forever (or panics on some platforms). std's Mutex is not re-entrant.
• Forgetting Arc::clone before move, so the first thread takes the only Arc.