m07-concurrency
CRITICAL: Use for concurrency/async. Triggers: E0277 Send Sync, cannot be sent between threads, thread, spawn, channel, mpsc, Mutex, RwLock, Atomic, async, await, Future, tokio, deadlock, race condition, 并发, 线程, 异步, 死锁
By actionbook · 2,921 installs
npx skills add actionbook/rust-skills --skill m07-concurrency
Source repository · Upstream listing
Concurrency
Layer 1: Language Mechanics
Core Question
Is this CPU bound or I/O bound, and what's the sharing model?
Before choosing concurrency primitives:
What's the workload type?
What data needs to be shared?
What's the thread safety requirement?
Error → Design Question
Error Don't Just Say Ask Instead
E0277 Send "Add Send bound" Should this type cross threads?
E0277 Sync "Wrap in Mutex" Is shared access really needed?
Future not Send "Use spawn local" Is async the right choice?
Deadlock "Reorder locks" Is the locking design correct?
Thinking Prompt
Before adding concurrency:
1. What's the workload?
CPU bound → threads (std::thread, rayon)
I/O bound → async (tokio, async std)
Mixed → hybrid approach
2. What's the sharing model?
No sharing → message passing (channels)
Immutable sharing → Arc<T
Mutable sharing → Arc<Mutex<T or Arc<RwLock<T
3. What are the Send/Sync requirements?
Cross thread ownership → Send
Cross thread references → Sync
Single thread async → spawn local
Trace Up ↑ (MANDATORY)
CRITICAL : Don't just fix the error. Trace UP to find domain constraints.
Domain Detection Table
Context Keywords Load Domain Skill Key Constraint
Web API, HTTP, axum, actix, handler domain web Handlers run on any thread
交易, 支付, trading, payment domain fintech Audit + thread safety
gRPC, kubernetes, microservice domain cloud native Distributed tracing
CLI, terminal, clap domain cli Usually single thread OK
Example: Web API + Rc Error
Generic Trace
Situation Trace To Question
Send/Sync in Web domain web What's the state management pattern?
Send/Sync in CLI domain cli Is multi thread really needed?
Mutex vs channels m09 domain Shared state or message passing?
Async vs threads m10 performance What's the workload profile?
Trace Down ↓
From design to implementation:
Send/Sync Markers
Marker Meaning Example
Send Can transfer ownership between threads Most types
Sync Can share references between threads Arc<T
!Send Must stay on one thread Rc<T
!Sync No shared refs across threads RefCell<T
Quick Reference
Pattern Thread Safe Blocking Use When
std::thread Yes Yes CPU bound parallelism
async/await Yes No I/O bound concurrency
Mutex<T Yes Yes Shared mutable state
RwLock<T Yes Yes Read heavy shared state
mpsc::channel Yes Optional Message passing
Arc<Mutex<T Yes Yes Shared mutable across threads
Decision Flowchart
Common Errors
Error Cause Fix
E0277 Send not satisfied Non Send in async Use Arc or spawn local
E0277 Sync not satisfied Non Sync shared Wrap with Mutex
Deadlock Lock ordering Consistent lock order
future is not Send Non Send across await Drop before await
MutexGuard across await Guard held during suspend Scope guard properly
Anti Patterns
Anti Pattern Why Bad Better
Arc<Mutex<T everywhere Contention, complexity Message passing
thread::sleep in async Blocks executor tokio::time::sleep
Holding locks across await Blocks other tasks Scope locks tightly
Ignoring deadlock risk Hard to debug Lock ordering, try lock
Async Specific Patterns
Avoid MutexGuard Across Await
Non Send Types in Async
Related Skills
When See
Smart pointer choice m02 resource
Interior mutability m03 mutability
Performance tuning m10 performance
Domain concurrency needs domain