Rust Send and Sync marker traits explained

WHAT THIS TESTS It probes whether you understand that Rust enforces data-race freedom at compile time using two auto-derived marker traits, and whether you can reason about why specific types do or do not implement them.

A GOOD ANSWER COVERS Send means a value of the type can be safely moved (ownership transferred) to another thread. Sync means it is safe for multiple threads to hold shared references to the value simultaneously; formally, T is Sync if and only if &T is Send. These traits are usually auto-implemented by the compiler when all fields qualify. The borrow checker and trait bounds on APIs like thread::spawn (which requires the closure be Send) reject code that would share data unsafely.

COMMON WRONG ANSWERS Saying Sync means the type is automatically locked or mutex-protected. Saying Send and Sync are the same thing. Claiming Rc is unsafe because it allocates on the heap rather than because of non-atomic reference counting.

LIKELY FOLLOW-UPS Why can you make a type Send via unsafe impl, and what obligations does that carry? What about Cell and RefCell being Send but not Sync? How does Mutex turn a non-Sync interior into a Sync wrapper?

ONE CONCRETE EXAMPLE Rc<T> stores a strong count that clone increments with a plain non-atomic add. If two threads cloned the same Rc concurrently, both could read the same count, increment, and write back, losing an update and eventually triggering a use-after-free when drops decrement to zero too early. Because of that risk Rc is neither Send nor Sync, so the compiler forbids moving it into a spawned thread. Arc performs the same counting with atomic fetch-add instructions, so concurrent clones are correct; Arc<T> is therefore Send and Sync whenever T itself is both. Swap Rc for Arc and the spawn compiles.