Send and Sync — the law across threads

Lesson 15 moved the law's check to run time: a reference count and a borrow flag, each a plain read-modify-write that assumes one thread. Threads break the assumption: two of them can reach one place at once, and if either writes, that is a data race — Lesson 01's hazard with the ordering removed. This lesson extends the law across threads without a single run-time check. The compiler answers two questions about every type — may a value move to another thread (Send), may a shared reference be used from several at once (Sync) — derives both from the type's parts, and thread::spawn's signature demands them. A data race becomes a type error; the only run-time price is the atomics and locks you ask for by name.

1 · A shared counter on two threads

A hit counter that several parts of a program update is the textbook case for Lesson 15's tools: Rc gives it several owners, RefCell lets any of them change it. Now let two threads count. In C++ this compiles, runs, and is a data race — two threads, one location, writes, no synchronization — which the language leaves undefined (C++ · 17, C++ · 19):

#include <thread>
int main() {
    int hits = 0;                                    // one place, two threads
    std::thread a([&] { for (int i = 0; i < 1000; ++i) ++hits; });
    std::thread b([&] { for (int i = 0; i < 1000; ++i) ++hits; });
    a.join(); b.join();
    return hits;                                     // a data race: undefined behavior
}

Lesson 01 wrote this with a plain local and got E0499: two exclusive names for one place. Lesson 15's answer to "several names, one counter" is Rc<RefCell<…>>, which the checker accepts on one thread. On two:

use std::cell::RefCell;
use std::rc::Rc;
use std::thread;

fn main() {
    let hits = Rc::new(RefCell::new(0));     // Lesson 15's shared, mutable counter
    let h2 = Rc::clone(&hits);               // a second owner, for the worker
    let worker = thread::spawn(move || *h2.borrow_mut() += 1);
    *hits.borrow_mut() += 1;                 // the main thread counts too
    worker.join().unwrap();
}

error[E0277]: `Rc<RefCell<i32>>` cannot be sent between threads safely
 --> src/main.rs:8:32
  |
8 |     let worker = thread::spawn(move || *h2.borrow_mut() += 1);
  |                  ------------- -------^^^^^^^^^^^^^^^^^^^^^^
  |                  |             |
  |                  |             `Rc<RefCell<i32>>` cannot be sent between threads safely
  |                  required by a bound introduced by this call
note: required because it's used within this closure
note: required by a bound in `spawn`

What would happen if it compiled? Both of Lesson 15's checks are ordinary integers updated by a read, an add and a write — std documents Rc's counts and RefCell's borrow counter as non-atomic. The worker drops h2 as it finishes, perhaps at the instant main drops hits: both read 2, both write 1, and the counter is never freed. Race a clone against a drop and the count can instead end one too low and reach zero while a handle still exists — a use-after-free. The borrow flag has the same window: both threads read "not borrowed", both get a RefMut, and two exclusive names exist at once — the overlap the flag was built to forbid. On two threads, the checker becomes the race.

The thread did nothing wrong; it is only a way for a second name to reach a place without being ordered after the first (Lesson 01 §2). The danger is in the data: which places a value lets two threads reach, and whether writes to them are synchronized. So the check belongs on the types of the values that cross — we need a question the compiler can ask of any type.

2 · Two questions about any type

A thread can receive a value in two ways, and each needs its own answer.

Hand it over. The new thread becomes the owner and, by Lesson 04's rule, the old name is dead. That is safe exactly when the move leaves the old thread no way to reach the value's places. It does for i32, String, Vec: each owns its bytes outright. It does not for Rc: the move carries one handle across, and the clones left behind still reach the same count. A type whose values may be moved to another thread is Send.

Share it. Both threads hold a shared reference and use it at once. The law allows any number of readers — provided reading only reads. Behind &i32 it does. Behind &Cell<i32> it does not: a shared reference to a Cell can write (Lesson 15), unsynchronized, so two threads holding one could write together. A type whose shared references may be used from several threads at once is Sync.

The second question is the first in disguise. To share t with another thread you send it a &T, so "may T be shared?" is "may a &T be sent?". Std defines it exactly so — T: Sync if and only if &T: Send — and implements it with one explicit rule for references. One notion, applied to a value and to a reference; §6 shows the compiler printing the definition inside an error.

So the compiler needs Send and Sync for every type — including the ones you write, which nobody will think to annotate.

3 · Derived from the parts

Moving a struct moves each field; if every field may move to another thread, so may the whole. Sharing a struct shares each field through &, so if every field is Sync, so is the struct. The answer is computable from the parts, and the compiler computes it unasked: Send and Sync are auto traits. The Reference lists five (Send, Sync, Unpin, UnwindSafe, RefUnwindSafe) and the rule: a struct, enum, tuple or array has one when all its parts do, a closure when all its captures do. You write no impl, so there is nothing to forget:

use std::rc::Rc;

fn is_send<T: Send>() {}                          // a probe: compiles only if T: Send

struct Job { name: String, data: Vec<u8> }        // no impl written anywhere
struct Session { id: u64, user: Rc<String> }      // one field opts out

fn main() {
    is_send::<Job>();                             // every field is Send, so Job is
    is_send::<Session>();                         // Rc<String> is not, so Session is not
}

error[E0277]: `Rc<String>` cannot be sent between threads safely
  = help: within `Session`, the trait `Send` is not implemented for `Rc<String>`
note: required because it appears within the type `Session`

Job passed with no ceremony. Session failed, and the compiler named the part that sank it: Rc<String>, "within" Session.

If every answer is assembled from parts, every "no" must start at a part that says no by itself. The Nomicon names three. Raw pointers are neither — it calls this more a lint than a necessity, since nothing can be done through one without unsafe, but it stops a type built on them from becoming Send or Sync by accident. UnsafeCell, the one primitive for mutation through a shared reference, is not Sync, so neither are Cell and RefCell, built on it. Rc carries explicit negative impls, as do a few std types with reasons of their own (§5). Negative impls exist only inside std; user code has no stable way to write one.

The other direction is a promise. Send and Sync are unsafe traits, so a hand-written impl is an unsafe impl: a human asserting what the compiler could not derive. Std's collections hold raw pointers yet are Send when their contents are, so each rests on such a promise; so does Arc, whose conditions say what it guarantees: T: Send + Sync. The compiler believes whoever writes one — even when it is false:

use std::rc::Rc;

fn is_send<T: Send>() {}

struct Session { id: u64, user: Rc<String> }
unsafe impl Send for Session {}       // a promise: the compiler checks nothing behind it

fn main() {
    is_send::<Session>();             // accepted, and false: every clone still shares one count
}

Who audits such promises is Lesson 19's subject. Here it is enough that the answer for any type is a proof over its structure whose leaves are primitives or promises. Building that proof is a trait solver's job — so let us run one.

4 · Run the solver

The widget runs the series' trait solver, extended with §6's closure rule. Each question is a real program, printed at the top of the canvas. The solver builds the proof tree, predicts rustc's error, and computes a repair — one local type change at a time, re-checked until the program is accepted or no type change can help. Against rustc 1.98.1, on every example in every question (60 programs) and 500 random programs with random structs, error codes and culprits agreed every time, and each of the 203 repairs it completed in that run compiled.

// sendsync.js, check(): what a closure handed to a thread must prove, capture by capture
prog.caps.forEach(function (c) {
  var a; try { a = parseType(c.type); } catch (e) { errors.push(c.type + ': ' + e.message); return; }
  var eff = c.mode;
  if (prog.kind === 'spawn' || prog.kind === 'scope') {
    if (prog.move) eff = 'val';                                   // move: every capture by value
    else if (eff === 'val' && TS.solve('Copy', a, env).ok) eff = 'ref';   // a Copy value is only borrowed
  }
  caps.push({ name: c.name, ast: a, eff: eff });
});
// … (a Send or Sync probe solves T itself)
var kids = caps.map(function (c) {
  var goalAst = c.eff === 'val' ? c.ast : { k: 'ref', mut: c.eff === 'mut', to: c.ast };
  return TS.solve('Send', goalAst, env).tree;
});
// … any failing leaf: E0277, and stop. Only when there is none:
if (prog.kind === 'spawn') {                          // type-checking passed; now 'static (borrowck)
  caps.forEach(function (c) {
    if (c.eff !== 'val') res.borrowed.push(c.name);   // E0373: the closure borrows a local
    if (borrows(c.ast)) res.nonStatic.push(c.name);   // E0521: the value itself borrows
  });
  if (res.borrowed.length) res.codes.push('E0373');
  if (res.nonStatic.length) res.codes.push('E0521');
}

What to try. Example 1, Rc<String> moved into thread::spawn, fails at the leaf Rc<String>: Send; one change fixes it, Rc → Arc. Example 3 asks only whether Arc<Cell<i32>> may move, yet the error is `Cell<i32>` cannot be shared — an Arc is Send only when its contents are Send and Sync — and the repair is Cell<i32> → AtomicI32. Example 4, &RefCell<i32>: Send, descends to RefCell<i32>: Sync: the definition of Sync as a proof step. Example 7, a MutexGuard, is Sync but not Send, and no type change helps. Examples 8 and 9 put the culprit inside a struct: the fix edits the field, and with unsafe impl Send the program is accepted "on the author's word". Example 10 lends a Cell<i32> to a scoped thread as &mut and is accepted; ask instead whether it may be shared and it is rejected. Last, ask example 2 the no-move question (thread::spawn(|| … &value …)): every type checks, the verdict is E0373, and the fix is move.

The ✗ leaves keep repeating a few names; read them as a table.

5 · The standard types, read off the rule

Each row follows from §3; the solver computed them, and they agree with a compiler-checked matrix:

Arc adds one thing: an atomic count. In machine code (rustc 1.98.1 -C opt-level=3, one AArch64 machine, Apple silicon, 2026-09):

use std::rc::Rc;
use std::sync::Arc;

#[inline(never)]                    // keep each as its own function, so we can read it
pub fn clone_rc(r: &Rc<u64>) -> Rc<u64> { Rc::clone(r) }

#[inline(never)]
pub fn clone_arc(a: &Arc<u64>) -> Arc<u64> { Arc::clone(a) }

clone_rc:                       clone_arc:
  ldr   x0, [x0]                  ldr   x0, [x0]
  ldr   x8, [x0]     ; load       mov   w8, #1
  adds  x8, x8, #1   ; add        ldadd x8, x8, [x0]   ; one indivisible add
  str   x8, [x0]     ; store      tbnz  x8, #63, trap  ; overflow guard
  b.hs  trap         ; overflow   ret
  ret

Another thread can run between clone_rc's load and its store; both then store the same count and an increment vanishes — §1's lost update in three instructions. ldadd reads, adds and writes as one indivisible step (C++ · 18). An indivisible update on every clone and drop is the price of making shared ownership Send, which is why std keeps both types and advises Rc when nothing crosses a thread. What Arc does not add is safety for the data: every clone gives its thread a &T, so T must be Sync, and the last clone drops T on its own thread, so T must be Send:

use std::cell::Cell;
use std::sync::Arc;

fn is_send<T: Send>() {}

fn main() {
    is_send::<Arc<Cell<i32>>>();   // every clone of the Arc reaches the same Cell
}

error[E0277]: `Cell<i32>` cannot be shared between threads safely
  = help: the trait `Sync` is not implemented for `Cell<i32>`
  = note: required for `Arc<Cell<i32>>` to implement `Send`

Mutex adds the other thing: exclusion. Mutex<T> is Sync when T is merely Send: the lock hands the inside to one thread at a time, so access to T moves between threads and is never shared — exactly Send's question. That condition cannot be dropped: if Mutex<Rc<i32>> were Sync, two threads could each lock it in turn, clone the Rc, and keep the clones after unlocking — one non-atomic count, two threads, no lock. So Arc<Mutex<T>> is two layers with two jobs: Arc supplies owners on several threads and asks for Send + Sync contents; Mutex turns a Send value into a Sync one. §1's counter, repaired:

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

fn main() {
    let hits = Arc::new(Mutex::new(0));      // an atomic count, and a lock
    let h2 = Arc::clone(&hits);
    let worker = thread::spawn(move || *h2.lock().unwrap() += 1);
    *hits.lock().unwrap() += 1;
    worker.join().unwrap();
    println!("hits = {}", *hits.lock().unwrap());
}

hits = 2

The table's odd pair follows the same way. A Receiver may move to one thread but not be shared: a channel promises one consumer. A MutexGuard may be shared — only &guard crosses, and dropping a reference does nothing — but not sent: its drop unlocks, and POSIX threads require the locking thread to unlock. And dyn Trait, as Lesson 13 promised: erasure forgot the concrete type, so no parts are left to derive from, and the compiler can only believe the object type — Box<dyn Fn()> is Send only when written Box<dyn Fn() + Send>.

The types carry the answers. What remains is where the compiler asks — and no function in the language is special there. It is a bound.

6 · The enforcement point: a bound on spawn

pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T,
    F: Send + 'static,
    T: Send + 'static,

Read it as a contract. F: Send: the closure moves to the new thread. T: Send: its result moves back to whoever calls join. 'static: the thread may outlive the caller, so the closure may hold no borrow of the caller's frame — E0373, and Lesson 14's move. A closure is a struct of captures, so it is Send when its captures are, each asked by how it is held: by value, T: Send; by shared reference, &T: Send, that is T: Sync; by exclusive reference, &mut T: Send, that is T: Send — the widget's closure node.

Nothing in the compiler knows what a thread is. Give any function the same bounds and it gets the same protection, and the same message:

use std::rc::Rc;

fn run_later<F: FnOnce() + Send + 'static>(job: F) { job() }   // no thread anywhere

fn main() {
    let user = Rc::new(String::from("ada"));
    run_later(move || println!("{user}"));
}

error[E0277]: `Rc<String>` cannot be sent between threads safely
note: required because it's used within this closure
note: required by a bound in `run_later`

The words "between threads" belong to the trait Send, not to spawn: they appear where no thread exists. Here the language meets the library: the compiler derives Send and Sync and checks 'static; std decides where to demand them.

The &mut rule looks too generous: why may an exclusive reference cross when T is only Send? Because while it lives it is the only name for T (Lesson 05). Handing it over moves the whole right to touch T for the loan's duration; nothing is shared, so Sync is not the question. A Cell can therefore be lent to a scoped thread — thread::scope, stable since Rust 1.63, joins its threads before returning, so they may borrow the caller's locals (Lesson 17 builds on it):

use std::cell::Cell;
use std::thread;

fn main() {
    let mut hits = Cell::new(0);
    thread::scope(|s| {
        let only = &mut hits;                    // the one name for hits while it lives
        s.spawn(move || only.set(only.get() + 1));
    });
    println!("{}", hits.get());
}

1

Shared, the same Cell is refused, and the last note is §2's definition in the compiler's words:

use std::cell::Cell;
use std::thread;

fn main() {
    let hits = Cell::new(0);
    thread::scope(|s| {
        s.spawn(|| hits.set(hits.get() + 1));    // captures &hits
        s.spawn(|| hits.set(hits.get() + 1));    // ...and so does this one
    });
}

error[E0277]: `Cell<i32>` cannot be shared between threads safely
  = help: the trait `Sync` is not implemented for `Cell<i32>`
  = note: if you want to do aliasing and mutation between multiple threads, use `std::sync::RwLock` or `std::sync::atomic::AtomicI32` instead
  = note: required for `&Cell<i32>` to implement `Send`

use std::thread;

struct Buffer(*mut u8);
unsafe impl Send for Buffer {}            // the author vouches for the whole struct

fn main() {
    let b = Buffer(std::ptr::null_mut());
    thread::spawn(move || { let _p = b.0; }).join().unwrap();   // captures only b.0
}

use std::rc::Rc;
use std::thread;

struct Session { id: u64, user: Rc<String> }

impl Session {
    fn describe(&self) -> String { format!("#{} {}", self.id, self.user) }
}

fn main() {
    let s = Session { id: 7, user: Rc::new(String::from("ada")) };
    let worker = thread::spawn(move || println!("{}", s.describe()));
    worker.join().unwrap();
}

error[E0277]: `Rc<String>` cannot be sent between threads safely
note: required because it appears within the type `Session`
note: required because it's used within this closure
note: required by a bound in `spawn`

So, given honest Send and Sync answers, no two threads reach a place while one writes unsynchronized. Both "honest" and "data race" are narrower than they sound.

7 · What the two traits do not promise

The Nomicon defines a data race precisely: two or more threads access one memory location concurrently, at least one writes, at least one access is unsynchronized. It is undefined behavior, and safe Rust excludes it — mostly through ownership (an exclusive reference cannot alias), and through Send and Sync for whatever mutates through a shared handle. A race condition is different: an answer that depends on scheduling — check a balance, release the lock, withdraw. Every access is synchronized and the answer is still wrong. The Nomicon calls preventing those impossible for a language that does not control the scheduler, and the Reference lists deadlocks and leaks as not unsafe. Lesson 17 gives the honest list.

Common mistakes / failure modes

Checkpoint exercise

Where this points next

The law now reaches across threads at no run-time cost beyond what we ask for by name: every type carries two derived answers, and thread::spawn is an ordinary function whose bounds demand them. But we have only watched single values cross — an Arc<Mutex<T>> here, a Cell lent to a scoped thread there. A real concurrent program must decide, for every piece of data, whether threads share it under a lock, hand it over as a message, or borrow it from a parent that waits for them — and must still face what the traits never promised: deadlock, race conditions, leaks. With these building blocks, how do we structure a real concurrent program, and what does the promise still leave to us?

Interview prompts

• What is the difference between Send and Sync? (§2 — Send: a value may move to another thread; Sync: &T may be used from several threads at once, defined as &T: Send. Cell is Send only; MutexGuard is Sync only.)
• Why is Rc not Send, and what does Arc change? (§1, §5 — clones on two threads would lose updates to one non-atomic count: too low is a use-after-free, too high a leak. Arc's count is an atomic read-modify-write: one ldadd per clone in §5's AArch64 build.)
• Is an Arc<T> always safe to send? (§5 — only if T: Send + Sync: every clone hands out &T, and the last drops T on its own thread; Arc<Cell<i32>> is neither.)
• Why is Mutex<T> Sync when T is only Send? (§5 — the lock admits one thread at a time, so access moves and is never shared; without T: Send, clones of an Rc could leave the lock on two threads.)
• How does the compiler prevent data races without knowing about threads? (§3, §6 — auto traits derived from each type's parts, plus a library function whose bounds demand them; any function with those bounds gets the same error.)
• Explain each bound in thread::spawn's signature. (§6 — F: Send: the closure moves to the new thread; T: Send: the result moves back through join; 'static: the thread may outlive its caller, so no borrow of the caller's frame may go.)
• What is an auto trait, and how does a type opt in or out? (§3 — implemented for a struct, enum, tuple, array or closure whose parts all have it; a "no" starts at a part that refuses — raw pointers, UnsafeCell, Rc; a manual "yes" is an unsafe impl, taken on trust.)
• Can a Cell<i32> be used from another thread? (§6 — moved: yes, it is Send; lent as &mut to a scoped thread: yes, the only name; shared as &Cell: no, Cell is not Sync.)

Companion reads: C++ · 17 Threads and races (the data race defined; a mutex that protects nothing by type), C++ · 18 Atomics and the memory model (what Arc's count relies on), C++ · 19 Undefined behavior (why a race is UB), Go · 08 Goroutines and Go · 11 When to share memory (the same hazard, caught by a race detector while running).