home / skills / zhanghandong / rust-skills / m07-concurrency

m07-concurrency skill

safe

/skills/m07-concurrency

This skill helps you design and reason about Rust concurrency, choosing appropriate primitives and avoiding deadlocks.

npx playbooks add skill zhanghandong/rust-skills --skill m07-concurrency

Review the files below or copy the command above to add this skill to your agents.

Files (5)

SKILL.md

6.2 KB

---
name: m07-concurrency
description: "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, 并发, 线程, 异步, 死锁"
user-invocable: false
---

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

---

## 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 await
let guard = mutex.lock().await;
do_async().await;  // guard still held!

// Good: scope the lock
{
    let guard = mutex.lock().await;
    // use guard
}  // guard dropped
do_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
```

---

## Related Skills

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

Overview

This skill guides Rust developers through concurrency and async decisions, error diagnosis, and safe implementations. It helps determine whether to use threads, async, or message passing, and shows how to trace errors like E0277 to design constraints before applying fixes. It emphasizes domain-aware choices and avoiding common anti-patterns.

How this skill works

It inspects error contexts and workload characteristics to recommend appropriate primitives (std::thread, rayon, tokio, channels, Arc/Mutex/RwLock, atomics). It traces UP to domain constraints (web, CLI, fintech, cloud-native) to decide thread-safety requirements and traces DOWN to map design choices to concrete implementations. It provides patterns for avoiding deadlocks, holding locks across await points, and handling non-Send/!Sync types.

When to use it

When you see E0277 Send/Sync or "future is not Send" errors
When deciding between CPU-bound parallelism and I/O-bound async
When sharing data across threads or tasks
When diagnosing deadlocks, race conditions, or contention
When migrating single-threaded code (Rc/RefCell) to multi-threaded contexts

Best practices

Classify workload: CPU-bound → threads/rayon; I/O-bound → async/await (tokio)
Trace UP to domain constraints before changing types or adding bounds
Prefer message passing (channels) when no shared mutable state is needed
Use Arc<T> for immutable shared data; Arc<Mutex<T>> or Arc<RwLock<T>> for mutable sharing, but minimize scope of locks
Avoid holding Mutex/RwLock guards across .await; drop guards before awaiting
Use spawn_blocking for CPU work in async runtimes and spawn_local only for truly non-Send futures

Example use cases

Fixing "Rc cannot be sent between threads" in a web handler by tracing to domain-web and switching to Arc<AppState>
Resolving "future is not Send" by dropping non-Send values before await or using spawn_local on a single-thread runtime
Choosing rayon or thread::spawn for CPU-heavy batch processing, with atomics for simple counters
Replacing global Arc<Mutex<T>> contention with channel-based message passing in a high-concurrency service
Preventing deadlock by enforcing consistent lock ordering and using try_lock for diagnostics

FAQ

Should I always add Send bounds when I see E0277?

No. Ask whether the type actually needs to cross thread boundaries. Tracing the domain and ownership model can show that single-threaded or spawn_local solutions are more appropriate.

When do I prefer channels over locks?

Use channels when components can exchange messages without shared mutable state. Channels reduce contention and often simplify reasoning compared to pervasive Arc<Mutex<T>>.

How do I handle non-Send types in async code?

Either convert to Send-safe types (Arc instead of Rc), ensure non-Send values are dropped before await, or run the task on a single-threaded runtime with spawn_local.