Rust concurrency exercises
Rust guarantees 'fearless concurrency' by preventing data races at compile time with Send and Sync traits. However, runtime deadlocks, Mutex poisoning after a panic, and channel starvation can still occur.
Practice debugging concurrent Rust applications.
The concurrency bugs you will meet
- Mutex lock guard held across an await point or long-running block causes thread starvation.
- A thread panicking while holding a Mutex lock poisons the mutex for all future callers.
- Sending on an mpsc channel where the receiver has been dropped returns a SendError.
- Rc<RefCell<T>> cannot be sent between threads; use Arc<Mutex<T>> or Arc<RwLock<T>>.
The exercises
Medium
Hard
- Deadlock in Nested Mutex Locks During Resource AccessAsync and race conditions
- Clone Arc Mutex inside thread spawning loopAsync and race conditions
- Poisoned mutex lock propagation after panicAsync and race conditions
- Channel receiver hangs due to retained sender cloneAsync and race conditions
- Unbounded channel memory leak under fast producerLogic
Errors you might be searching for
More JavaScript practice by topic
Questions
What is Mutex poisoning in Rust?
If a thread panics while holding a std::sync::Mutex lock, the mutex becomes poisoned so subsequent .lock() calls receive a PoisonError rather than reading potentially corrupted state.