M07 Concurrency
Guide solo builders through Rust concurrency and async design when compiler errors, deadlocks, or thread-safety questions block backend or systems code.
Overview
m07-concurrency is an agent skill most often used in Build (also Ship) that turns Rust concurrency and async compiler errors into workload, sharing, and Send/Sync design decisions.
Install
npx skills add https://github.com/actionbook/rust-skills --skill m07-concurrencyWhat is this skill?
- Maps E0277 Send/Sync and related errors to design questions instead of blind bound fixes
- Three-step workload model: CPU-bound threads, I/O-bound async, or hybrid
- Sharing model chooser: message passing, Arc<T>, or Arc<Mutex/RwLock<T>>
- Explicit trace-up mandate to connect symptoms to workload and sharing design
- Bilingual triggers for async, deadlock, race, and thread spawn scenarios
- 4-row error-to-design-question table (E0277 Send/Sync, Future not Send, deadlock)
- 3-step thinking prompt (workload, sharing model, Send/Sync requirements)
Adoption & trust: 980 installs on skills.sh; 1.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You hit E0277, non-Send futures, or deadlock errors and need a principled pick between threads, async, channels, and locks—not another layer of Mutex.
Who is it for?
Solo builders writing or debugging concurrent Rust backends with tokio/async-std, std::thread, channels, or Arc<Mutex/RwLock> who want error-driven design guidance.
Skip if: Teams that only need high-level async tutorials without compiler errors, or non-Rust stacks where Send/Sync does not apply.
When should I use this skill?
CRITICAL for concurrency/async: E0277 Send/Sync, cannot be sent between threads, thread/spawn, channel/mpsc, Mutex/RwLock/Atomic, async/await/Future, tokio, deadlock, race condition, or 并发/线程/异步/死锁.
What do I get? / Deliverables
You leave with a workload-appropriate concurrency model (threads, async, or hybrid), a sharing strategy, and bounds that match real cross-thread needs instead of copy-paste fixes.
- Documented workload and sharing model choice
- Send/Sync-aware type and spawn strategy
- Concurrency fix aligned to channels or Arc locks rather than ad-hoc patches
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Concurrency choices—threads vs async, channels vs locks—are made while implementing Rust services, CLIs, and APIs, so Build → backend is the canonical shelf. Send/Sync, tokio, Mutex, and mpsc are backend and systems concerns, not frontend or docs work.
Where it fits
Pick rayon versus tokio before implementing a new HTTP worker pool in a Rust API.
Decide whether to pass work over mpsc channels or share state with Arc<Mutex> for an agent-side Rust tool.
Reframe a deadlock in lock ordering as a sharing-model mistake during code review.
Trace an E0277 on a Future through Send requirements before adding spawn_local as a shortcut.
How it compares
Use as a Rust-specific concurrency design checklist during coding—not as a generic “add Send bound” snippet or an MCP integration.
Common Questions / FAQ
Who is m07-concurrency for?
Solo and indie builders and their coding agents working on Rust APIs, CLIs, or systems code where threads, async, channels, or locks are in play.
When should I use m07-concurrency?
During Build when choosing thread vs async models or shared state; during Ship when fixing E0277, non-Send futures, deadlocks, or race conditions; whenever SKILL.md triggers mention spawn, mpsc, Mutex, tokio, or 并发/异步.
Is m07-concurrency safe to install?
Treat it as procedural agent knowledge in your repo—review the Security Audits panel on this Prism page and your org policy before enabling it in automated agents.
SKILL.md
READMESKILL.md - M07 Concurrency
# 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 ``` "Rc cannot be sent between threads" in Web API context ↑ DETECT: "Web API" → Load domain-web ↑ FIND: domain-web says "Shared state must be thread-safe" ↑ FIND: domain-web says "Rc in state" is Common Mistake ↓ DESIGN: Use Arc<T> with State extractor ↓ IMPL: axum::extract::State<Arc<AppConfig>> ``` ### Generic Trace ``` "Send not satisfied for my type" ↑ Ask: What domain is this? Load domain-* skill ↑ Ask: Does this type need to cross thread boundaries? ↑ Check: m09-domain (is the data model correct?) ``` | 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: ``` "Need parallelism for CPU work" ↓ Use: std::thread or rayon "Need concurrency for I/O" ↓ Use: async/await with tokio "Need to share immutable data across threads" ↓ Use: Arc<T> "Need to share mutable data across threads" ↓ Use: Arc<Mutex<T>> or Arc<RwLock<T>> ↓ Or: channels for message passing "Need simple atomic operations" ↓ Use: AtomicBool, AtomicUsize, etc. ``` --- ## 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