Concurrency Highlights Summary

Every highlight bullet from the 11 pages in this section, gathered on one page and grouped by the page it came from.

Fearless Concurrency in Rust

• Send and Sync are compiler-checked contracts, not runtime checks.
• A data race is specifically two threads racing on the same memory with at least one write and no synchronization.
• Shared-state concurrency serializes access; message-passing concurrency transfers ownership instead.
• Most auto traits are derived automatically from a type's fields, not written by hand.
• Choosing between locks and channels is a design decision, not a syntax preference.

Concurrency Basics

• Rust 1.97.0 with std::thread is required for concurrency examples
• Understand ownership and move closures before spawning threads
• std::thread::spawn runs a closure on a new OS thread
• join blocks until the thread finishes and returns a Result
• Use move to transfer ownership of data across thread boundaries
• Threads can return values through their JoinHandle

Send & Sync

• Send and Sync are auto-implemented marker traits
• The compiler uses Send and Sync to reject data races
• Send allows ownership transfer to another thread
• Sync allows sharing references across threads
• Arc is Send and Sync when its inner type T is Send and Sync
• Mutex is Sync when its inner type T is Send

Channels

• Use channels for thread communication without sharing mutable state
• Rust's mpsc provides multi-producer, single-consumer channels
• mpsc::channel creates an unbounded queue that can grow indefinitely
• send moves ownership of data; recv blocks until data is available
• Clone the sender to allow multiple producers to send messages
• Drop all senders so the receiver's iteration can complete

Mutex & RwLock

• Mutex and RwLock serialize access to shared mutable state
• Pair Mutex or RwLock with Arc for multi-thread sharing
• RwLock allows concurrent readers or a single writer
• Mutex provides exclusive access for one guard at a time
• A poisoned lock indicates a thread panicked while holding it
• Acquire locks in a fixed global order to prevent deadlocks

Arc for Shared State

• Arc enables multiple threads to share ownership of heap-allocated data
• Combine Arc with Mutex or RwLock for shared mutable state
• Arc::clone increments the reference count, it does not deep clone data
• Use Weak references with Arc to prevent memory leaks from cycles
• Arc is Send + Sync, making it safe for concurrent use across threads
• Avoid deep cloning by mistake; use Arc::clone(&arc) for new handles

Atomics & Ordering

• Atomic types provide lock-free operations on integers, booleans, and pointers
• Choose the weakest memory ordering that remains correct for your use case
• Use fetch_add with Relaxed for simple monotonic counters
• Pair Release stores with Acquire loads for handoff patterns like shutdown flags
• Avoid SeqCst everywhere; it can hide bugs and reduce performance
• Atomics protect themselves, not neighboring memory without proper ordering

Scoped Threads

• std::thread::scope spawns threads that borrow parent stack data
• Scoped threads do not require a 'static bound for borrowed references
• The scope blocks the parent thread until all child threads complete
• Use thread::scope for parallelizing work over borrowed slices or stack buffers
• Avoid thread::scope for fire-and-forget background work
• Async tasks cannot borrow stack data across .await like scoped threads

Data Parallelism with Rayon

• Rayon uses a work-stealing thread pool for data parallelism
• Use par_iter for parallel maps, filters, reductions, and sorting
• par_iter splits work across Rayon's thread pool
• Avoid blocking I/O within par_iter closures to prevent pool starvation
• Rc is not Send; use Arc or owned data for parallel iteration
• For tiny collections, sequential iterators are more efficient due to overhead

Deadlocks & Race Conditions

• Rust prevents data races at compile time in safe code
• Deadlocks occur when threads wait on each other indefinitely
• Logic races produce wrong results when operations are not atomic
• Always lock mutexes in the same consistent order to prevent deadlocks
• Use channels, ownership transfer, or immutability to reduce locks
• Catch panics at thread boundaries to avoid mutex poisoning deadlocks

Concurrency Best Practices

• Profile before choosing threads, Rayon, or async
• Prefer message passing over shared mutation
• Keep critical sections short to minimize lock scope
• Use thread::scope when borrowing stack data
• Prefer bounded channels to prevent OOM errors
• Do not block the async executor with mutex.lock()