Thread Safety Traits: The Send & Sync Formalisms

In C and C++, thread safety is an undocumented convention: developers must remember which objects can be passed across threads and which pointers must be guarded by locks. A single mistake triggers silent data races.

In Rust, thread safety is formally proven at compile time through two built-in marker traits: Send and Sync.

1. Defining Send and Sync#

Unlike normal traits that define methods, Send and Sync are marker traits: they have zero methods and exist purely to convey capabilities to the compiler.

The Equivalence Theorem#

The relationship between Send and Sync is formalized by a fundamental equivalence:

A type $T$ is Sync if and only if a shared immutable reference to $T$ ($\&T$) implements Send.

2. Auto-Trait Derivation Rules#

Send and Sync are auto traits: the compiler automatically implements them for your custom structs and enums if all of their constituent fields implement them:

For a compound struct $C$ containing fields $F_1, F_2, \dots, F_k$:

If a struct contains even a single field that is not thread safe (such as an Rc pointer or raw pointer), the entire struct automatically loses Send or Sync.

3. The Anatomy of Non-Thread-Safe Types#

Understanding why certain types are marked !Send or !Sync illuminates how Rust eliminates concurrency bugs:

Why Rc<T> is !Send and !Sync#

Rc<T> uses standard, non-atomic CPU instructions (count += 1) to increment its reference count. If two threads cloned an Rc concurrently, a CPU data race would corrupt the counter, causing premature memory deallocation and use-after-free bugs!

1
2
3
4
5
6
7
8
9
10
11
12
13
use std::rc::Rc;
use std::thread;

fn main() {
    let rc_value = Rc::new(42);

    // COMPILE ERROR: `Rc<i32>` cannot be sent between threads safely
    // thread::spawn(move || {
    //     println!("{}", rc_value);
    // });
    
    // SOLUTION: Use Arc<T> instead of Rc<T>!
}

4. Concept Verification#

Test your understanding of Send and Sync invariants: