AdvancedConcurrency
Lab: concurrent Rust
Apply threads, shared state, channels, and async to realistic concurrency decisions.
Lab · optionalRustAdvanced10 min
Recommended first
By the end of this lesson you will be able to:
- Choose between threads and async for a given workload
- Identify when Mutex vs channels is the right synchronisation tool
- Reason about data races and why Rust prevents them at compile time
- Recognise async pitfalls like blocking the executor
Optional scenario lab. Rust's ownership model makes concurrency bugs compile-time errors — but you still need to choose the right abstraction. Practice the judgment calls here.
Scenarios: concurrent Rust
- 1.Your service needs to handle thousands of simultaneous network connections with minimal CPU work per connection. Best model?
- 2.Several threads need to update a shared counter. Best synchronisation primitive?
- 3.If a type implements Send but not Sync, it can be transferred to another thread but cannot be shared by reference across threads simultaneously.
- 4.Inside an async function you call
std::thread::sleep(Duration::from_secs(5)). What happens? - 5.You try to share a
Vec<i32>between two threads that both write to it, without any synchronisation. In Rust, this:
The concurrency mindset: let the ownership system guide you — if it compiles without unsafe, the data races are gone. The remaining judgment is about the right abstraction: threads for CPU work, async for I/O, channels for ownership transfer, Mutex for shared state.
Finished reading? Mark it complete to track your progress.