Rust Send and Sync

Send and Sync are Rust's two auto-traits for thread safety. They're auto-derived (every struct gets them iff all fields have them), and they govern what the borrow checker permits across threads:

• T: Send — values of T can be moved to another thread. Rc<T> is not Send (refcount race); Arc<T> is Send if T: Send + Sync.
• T: Sync — &T can be shared across threads. Equivalently, T: Sync ⇔ &T: Send. Cell<T> is not Sync (interior mutation without synchronization); Mutex<T>: Sync only requires T: Send.

The non-obvious rules that make this load-bearing in practice:

The &T: Send ⇔ T: Sync rule is the one that surprises people, and it's the source of the rust-async-trait-sync-bound gotcha — capturing &self in a Send future silently demands Self: Sync, even when nothing in the code obviously asks for it.

Workarounds when you have a !Sync field but need a Send future:

• Wrap the field in Mutex<T> — Mutex<T>: Sync only requires T: Send
• Use &mut self instead of &self — &mut T: Send only needs T: Send
• Make the captured value owned (move into the future) — owned-vs-borrowed avoids the issue

For the language-design rationale (&mut as uniqueness, not mutation), Niko Matsakis's "Focusing on ownership" is canonical. safety-in-an-unsafe-world uses Send as its worked example of a library-defined safety property: the trait's meaning lives entirely in its doc comment, unsafe impl is the enforcement, and the F: Send bound on spawn is what justifies the pthread_create call underneath.

Cross-references: rust-async-trait-sync-bound, message-passing-vs-shared-memory.