M07 Concurrency

作者 actionbook5c40d3ad7851無授權條款1.5K 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫6 週前更新

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, 并发, 线程, 异步, 死锁

僅含說明Software Development

AI 產生的概覽

指導 Rust 並行與非同步設計決策，從 Send/Sync 錯誤到選擇執行緒、通道或非同步執行環境。

功能: 這個技能是推理 Rust 並行與非同步程式設計的參考文件。它把 E0277 Send/Sync、非 Send future 等常見編譯錯誤對應到背後的设计問題，並提供在執行緒、async/await、通道、Arc、Mutex、RwLock 與原子型別之間做選擇的決策表。它也列出反模式以及非同步特有的陷阱，例如在 await 期間持有 MutexGuard。
適用情境: 在處理 Rust 並行或非同步問題時使用，尤其是 Send/Sync trait 錯誤、死鎖、競態條件，或在執行緒與非同步之間做選擇時。在選擇跨執行緒或跨任務存取資料的共享模型時也很有用。
執行需求: 不需要指令碼或執行環境相依性，是純說明性參考文件。它假定讀者熟悉 Rust 並行概念，並可能引用 domain-web、domain-cli、m09-domain、m10-performance 等相關技能。

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:

What's the workload?
- CPU-bound → threads (std::thread, rayon)
- I/O-bound → async (tokio, async-std)
- Mixed → hybrid approach
What's the sharing model?
- No sharing → message passing (channels)
- Immutable sharing → Arc<T>
- Mutable sharing → Arc<Mutex<T>> or Arc<RwLock<T>>
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>>

"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?)

"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.

"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

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

What type of work?├─ CPU-bound → std::thread or rayon├─ I/O-bound → async/await└─ Mixed → hybrid (spawn_blocking)
Need to share data?├─ No → message passing (channels)├─ Immutable → Arc<T>└─ Mutable →   ├─ Read-heavy → Arc<RwLock<T>>   └─ Write-heavy → Arc<Mutex<T>>   └─ Simple counter → AtomicUsize
Async context?├─ Type is Send → tokio::spawn├─ Type is !Send → spawn_local└─ Blocking code → spawn_blocking

What type of work?├─ CPU-bound → std::thread or rayon├─ I/O-bound → async/await└─ Mixed → hybrid (spawn_blocking)
Need to share data?├─ No → message passing (channels)├─ Immutable → Arc<T>└─ Mutable →   ├─ Read-heavy → Arc<RwLock<T>>   └─ Write-heavy → Arc<Mutex<T>>   └─ Simple counter → AtomicUsize
Async context?├─ Type is Send → tokio::spawn├─ Type is !Send → spawn_local└─ Blocking code → spawn_blocking

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

rust

// Bad: guard held across awaitlet guard = mutex.lock().await;do_async().await;  // guard still held!
// Good: scope the lock{    let guard = mutex.lock().await;    // use guard}  // guard droppeddo_async().await;

// Bad: guard held across awaitlet guard = mutex.lock().await;do_async().await;  // guard still held!
// Good: scope the lock{    let guard = mutex.lock().await;    // use guard}  // guard droppeddo_async().await;

Non-Send Types in Async

rust

// Rc is !Send, can't cross await in spawned task// Option 1: use Arc instead// Option 2: use spawn_local (single-thread runtime)// Option 3: ensure Rc is dropped before .await

// Rc is !Send, can't cross await in spawned task// Option 1: use Arc instead// Option 2: use spawn_local (single-thread runtime)// Option 3: ensure Rc is dropped before .await

Related Skills

來源與署名

來源：actionbook/rust-skills位於skills/m07-concurrency提交5c40d3a

授權條款：無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架

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>`

When	See
Smart pointer choice	m02-resource
Interior mutability	m03-mutability
Performance tuning	m10-performance
Domain concurrency needs	domain-*

M07 Concurrency

Concurrency

Core Question

Error → Design Question

Thinking Prompt

Trace Up ↑ (MANDATORY)

Domain Detection Table

Example: Web API + Rc Error

Generic Trace

Trace Down ↓

Send/Sync Markers

Quick Reference

Decision Flowchart

Common Errors

Anti-Patterns

Async-Specific Patterns

Avoid MutexGuard Across Await

Non-Send Types in Async

Related Skills

來源與署名

更多來自 actionbook/rust-skills 的技能

Rust Trait Explorer

Rust Symbol Analyzer

Rust Skill Creator

Rust Router

Rust Refactor Helper

Rust Daily

更多Software Development技能

Playground

M5 Onboard

Cardputer Buddy

Web Design Guidelines

Vercel React Native Skills

Vercel React Best Practices