Fearless concurrency: Send and Sync

Threads, shared state and channels

1use std::sync::{mpsc, Arc, Mutex};2use std::thread;3 4fn main() {5    let hits = Arc::new(Mutex::new(0));6    let mut handles = vec![];7    for _ in 0..8 {8        let hits = Arc::clone(&hits);9        handles.push(thread::spawn(move || {10            for _ in 0..1000 {11                *hits.lock().unwrap() += 1; // the guard unlocks when dropped12            }13        }));14    }15    for h in handles {16        h.join().unwrap();17    }18    println!("hits = {}", *hits.lock().unwrap());19 20    let data = vec![1, 2, 3, 4];21    let (left, right) = data.split_at(2);22    let (a, b) = thread::scope(|s| { // scoped threads may borrow local data23        let ha = s.spawn(|| left.iter().sum::<i32>());24        let hb = s.spawn(|| right.iter().sum::<i32>());25        (ha.join().unwrap(), hb.join().unwrap())26    });27    println!("{a} + {b}");28 29    let (tx, rx) = mpsc::channel();30    thread::spawn(move || tx.send(String::from("moved through a channel")).unwrap());31    println!("{}", rx.recv().unwrap());32}

It prints hits = 8000 every time, then 3 + 7, then moved through a channel.

• Arc<Mutex<T>> is shared, mutable state. Arc gives every thread an owner; Mutex makes access exclusive. The data is inside the mutex, so it is impossible to touch it without locking. lock() returns a guard, and dropping the guard unlocks. unwrap() deals with poisoning: if a thread panicked while holding the lock, later lock() calls return an error.
• Scoped threads are joined before thread::scope returns, so they can borrow left and right from the stack without Arc or 'static.
• Channels move ownership: after send, the sending thread can't use the value any more. mpsc means many producers, one consumer.

What the compiler stops

Move an Rc into thread::spawn and the program doesn't compile (output shortened):

1error[E0277]: `Rc<i32>` cannot be sent between threads safely2  = help: within `{closure@src/main.rs:5:27: 5:34}`, the trait `Send` is not implemented for `Rc<i32>`3note: required by a bound in `spawn`4  |     F: Send + 'static,

The same mechanism rejects sharing a RefCell between threads (not Sync), mutating a captured variable from two threads without a lock, and moving a MutexGuard to another thread (guards aren't Send, because the underlying system locks must be released by the thread that acquired them).

What it doesn't stop

Data-race freedom isn't freedom from all concurrency bugs. Deadlocks, lock-ordering mistakes, starvation and higher-level races (read, decide, then write under two separate locks) are still possible. Keep critical sections short, take locks in a consistent order, and prefer message passing or owning data per thread when the design allows.

Your own types get Send and Sync automatically when all their fields have them. Implementing them by hand is unsafe impl Send for MyType {}: a promise the compiler can't check, needed only for types built on raw pointers.

For heavier data parallelism, crates such as rayon turn iter() into par_iter() and rely on the same Send/Sync bounds to stay safe. std::sync::atomic provides lock-free counters and flags, with explicit memory orderings.