Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
zhanghandong avatar

M07 Concurrency

  • 858 installs
  • 1.3k repo stars
  • Updated May 24, 2026
  • zhanghandong/rust-skills

This is a copy of m07-concurrency by actionbook - installs and ranking accrue to the original listing.

m07-concurrency is a Rust language skill that correctly diagnoses and resolves concurrency errors involving Send, Sync, threads, channels, async, and deadlocks for developers implementing CPU-bound or I/O-bound Rust back

About

m07-concurrency is a Layer 1 language mechanics skill from zhanghandong/rust-skills marked CRITICAL for concurrency and async work in Rust. The skill triggers on compiler errors like E0277 Send and Sync violations, cannot be sent between threads messages, and keywords including spawn, mpsc, Mutex, RwLock, Atomic, tokio, Future, deadlock, and race condition. Before choosing primitives, m07-concurrency forces developers to answer whether work is CPU-bound or I/O-bound and what sharing model applies. Error tables map E0277 Send failures to design questions instead of blind trait bound fixes. Developers reach for m07-concurrency when Rust concurrency code fails to compile or deadlocks appear in threaded, channel-based, or tokio async codebases.

  • Translates compiler errors like E0277 into precise design questions about workload type and sharing model
  • Provides decision framework distinguishing CPU-bound vs I/O-bound workloads before choosing primitives
  • Maps sharing needs to correct patterns: message passing, Arc<T>, Arc<Mutex<T>>, Arc<RwLock<T>>
  • Includes mandatory Trace Up workflow and error-to-design question table for Send, Sync, Future, and deadlock cases
  • Covers both std::thread/rayon for CPU and tokio/async-std for async Rust concurrency

M07 Concurrency by the numbers

  • 858 all-time installs (skills.sh)
  • +9 installs in the week ending Jul 28, 2026 (Skillselion tracking)
  • Security screen: MEDIUM risk (skills.sh audit)
  • Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/zhanghandong/rust-skills --skill m07-concurrency

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs858
repo stars1.3k
Security audit3 / 3 scanners passed
Last updatedMay 24, 2026
Repositoryzhanghandong/rust-skills

How do you fix Rust Send and Sync concurrency errors?

Correctly diagnose and resolve Rust concurrency errors involving Send, Sync, threads, channels, async, and deadlock conditions.

Who is it for?

Rust developers hitting E0277, thread safety errors, or async tokio deadlocks who need workload-aware concurrency guidance.

Skip if: Developers writing single-threaded Rust with no async, threads, or shared mutable state requirements.

When should I use this skill?

Rust code hits E0277, Send or Sync errors, spawn or channel issues, tokio async failures, or deadlock reports.

What you get

Resolved Send and Sync trait errors, correct concurrency primitive choice, and working threaded or async Rust code without deadlocks.

  • Fixed concurrency implementation
  • Correct primitive selection rationale

By the numbers

  • Layer 1 language mechanics module m07 in zhanghandong/rust-skills
  • Triggers on compiler error E0277 and Send Sync violations

Files

SKILL.mdMarkdownGitHub ↗

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

ErrorDon't Just SayAsk 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 KeywordsLoad Domain SkillKey Constraint
Web API, HTTP, axum, actix, handlerdomain-webHandlers run on any thread
交易, 支付, trading, paymentdomain-fintechAudit + thread safety
gRPC, kubernetes, microservicedomain-cloud-nativeDistributed tracing
CLI, terminal, clapdomain-cliUsually 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?)
SituationTrace ToQuestion
Send/Sync in Webdomain-webWhat's the state management pattern?
Send/Sync in CLIdomain-cliIs multi-thread really needed?
Mutex vs channelsm09-domainShared state or message passing?
Async vs threadsm10-performanceWhat'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

MarkerMeaningExample
SendCan transfer ownership between threadsMost types
SyncCan share references between threadsArc<T>
!SendMust stay on one threadRc<T>
!SyncNo shared refs across threadsRefCell<T>

Quick Reference

PatternThread-SafeBlockingUse When
std::threadYesYesCPU-bound parallelism
async/awaitYesNoI/O-bound concurrency
Mutex<T>YesYesShared mutable state
RwLock<T>YesYesRead-heavy shared state
mpsc::channelYesOptionalMessage passing
Arc<Mutex<T>>YesYesShared 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

ErrorCauseFix
E0277 Send not satisfiedNon-Send in asyncUse Arc or spawn_local
E0277 Sync not satisfiedNon-Sync sharedWrap with Mutex
DeadlockLock orderingConsistent lock order
future is not SendNon-Send across awaitDrop before await
MutexGuard across awaitGuard held during suspendScope guard properly

---

Anti-Patterns

Anti-PatternWhy BadBetter
Arc<Mutex<T>> everywhereContention, complexityMessage passing
thread::sleep in asyncBlocks executortokio::time::sleep
Holding locks across awaitBlocks other tasksScope locks tightly
Ignoring deadlock riskHard to debugLock ordering, try_lock

---

Async-Specific Patterns

Avoid MutexGuard Across Await

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

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

WhenSee
Smart pointer choicem02-resource
Interior mutabilitym03-mutability
Performance tuningm10-performance
Domain concurrency needsdomain-*

Related skills

How it compares

Use m07-concurrency for Rust-specific Send, Sync, and async errors; use generic debugging skills for language-agnostic performance tuning.

FAQ

What Rust errors trigger m07-concurrency?

m07-concurrency activates on E0277 Send and Sync errors, cannot be sent between threads messages, and concurrency keywords including spawn, mpsc, Mutex, RwLock, tokio, async, await, deadlock, and race condition.

What question should Rust developers answer before picking concurrency primitives?

m07-concurrency requires deciding whether the workload is CPU-bound or I/O-bound and identifying the data sharing model before selecting threads, channels, Mutex, RwLock, or tokio async primitives.

Is M07 Concurrency safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Backend & APIsbackendintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.