What are the Send and Sync traits in Rust and what do they guarantee?
Understand Rust's Send and Sync marker traits: what each guarantees, why Rc isn't Send, and how they make thread safety a compile-time check.
Expected Interview Answer
Send and Sync are auto-marker traits that encode thread-safety in the type system: a type is Send if it can be safely moved to another thread, and Sync if a shared reference (&T) can be safely accessed from multiple threads at once.
The compiler implements both automatically for a type when all of its fields are Send/Sync, so most types get them for free. A type is Sync exactly when &T is Send. These bounds let the standard library require, for example, that closures passed to thread::spawn are Send and that Arc<T> only shares T across threads when T is Sync, turning data-race prevention into a compile-time guarantee rather than a runtime hope.
- Data races become compile-time errors instead of runtime bugs
- Thread-safety is inferred automatically for most types
- APIs express concurrency requirements through trait bounds
- Non-thread-safe types like Rc are rejected at the boundary
- No runtime cost — the checks vanish after compilation
AI Mentor Explanation
Send is like a player being cleared to physically transfer to another team's dressing room, while Sync is like a live scoreboard everyone in both dugouts can read at once without confusion. A twelfth-man clipboard meant for one bench only (Rc) is barred from crossing sides, but an official league scoreboard is safe for all to watch together.
Step-by-Step Explanation
Step 1
Auto-derivation
The compiler grants Send/Sync automatically when every field of a type already implements them.
Step 2
The Sync definition
A type T is Sync precisely when &T is Send — shared references can cross thread boundaries safely.
Step 3
Opting out
Types holding raw pointers or non-atomic sharing (Rc, Cell) deliberately lack these traits via negative impls or field types.
Step 4
Bounds on APIs
thread::spawn requires F: Send and Arc<T>: Send + Sync requires T: Send + Sync, enforcing safety at call sites.
Step 5
Unsafe overrides
When you uphold invariants the compiler cannot see, you may write unsafe impl Send/Sync manually, taking responsibility for correctness.
What Interviewer Expects
- Clear distinction between moving a value (Send) and sharing a reference (Sync)
- Knowing Sync is defined in terms of &T being Send
- Awareness that both are auto traits derived structurally
- Concrete examples: Rc is neither, Arc<Mutex<T>> is both
- Understanding these are compile-time guarantees with no runtime cost
Common Mistakes
- Saying Sync means a type is thread-safe to mutate freely without a lock
- Confusing Send and Sync or thinking they are the same guarantee
- Believing you must implement them manually for ordinary types
- Not knowing why Rc lacks Send while Arc has it (non-atomic refcount)
- Assuming they impose runtime overhead
Best Answer (HR Friendly)
“Send and Sync are labels Rust attaches to types to describe how they behave across threads: Send means a value can be handed off to another thread, and Sync means several threads can safely look at it at the same time. The compiler figures this out automatically, so unsafe sharing is caught before the program ever runs.”
Code Example
use std::rc::Rc;
use std::sync::Arc;
use std::thread;
fn main() {
// Arc<i32> is Send + Sync, so this compiles.
let shared = Arc::new(42);
let a = Arc::clone(&shared);
thread::spawn(move || {
println!("from thread: {}", a);
})
.join()
.unwrap();
// Rc<i32> is NOT Send: uncommenting the block below fails to compile
// because Rc uses a non-atomic reference count.
let _local = Rc::new(1);
// thread::spawn(move || println!("{}", _local)); // error[E0277]
}Follow-up Questions
- Why is Rc not Send but Arc is?
- How does Sync relate to Send through the &T type?
- When would you write an unsafe impl Send or Sync?
- Why is Cell<T> not Sync even though it is Send?
- How do the thread::spawn bounds use these traits?
MCQ Practice
1. A type T is Sync if and only if which of the following holds?
Sync is defined so that a shared reference &T can be sent across threads — that is, &T is Send.
2. Why is Rc<T> not Send?
Rc uses a plain non-atomic counter; sharing it across threads could corrupt the count, so it is deliberately not Send.
3. What runtime cost do the Send and Sync checks add?
Send and Sync are marker traits checked by the compiler; they disappear at runtime and add no overhead.
Flash Cards
What does Send guarantee? — A value of the type can be safely moved (transferred) to another thread.
What does Sync guarantee? — A shared reference &T can be accessed from multiple threads at once; equivalently, &T is Send.
Why is Rc not Send but Arc is? — Rc's reference count is non-atomic; Arc uses atomic counting, making cross-thread sharing safe.
Who implements Send/Sync for most types? — The compiler, automatically, when all fields already implement them.
Runtime cost of Send/Sync? — None — they are compile-time marker traits with zero runtime overhead.