โ† Back to list
rustfs

m07-concurrency

by rustfs

๐Ÿš€2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.

โญ 20,125๐Ÿด 866๐Ÿ“… Jan 23, 2026

SKILL.md


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, ๅนถๅ‘, ็บฟ็จ‹, ๅผ‚ๆญฅ, ๆญป้”"

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
    • Mutable sharing โ†’ Arc<Mutex> or Arc<RwLock>
  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> 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

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

Score

Total Score

90/100

Based on repository quality metrics

โœ“SKILL.md

SKILL.mdใƒ•ใ‚กใ‚คใƒซใŒๅซใพใ‚Œใฆใ„ใ‚‹

+20
โœ“LICENSE

ใƒฉใ‚คใ‚ปใƒณใ‚นใŒ่จญๅฎšใ•ใ‚Œใฆใ„ใ‚‹

+10
โœ“่ชฌๆ˜Žๆ–‡

100ๆ–‡ๅญ—ไปฅไธŠใฎ่ชฌๆ˜ŽใŒใ‚ใ‚‹

+10
โœ“ไบบๆฐ—

GitHub Stars 1000ไปฅไธŠ

+15
โœ“ๆœ€่ฟ‘ใฎๆดปๅ‹•

1ใƒถๆœˆไปฅๅ†…ใซๆ›ดๆ–ฐ

+10
โœ“ใƒ•ใ‚ฉใƒผใ‚ฏ

10ๅ›žไปฅไธŠใƒ•ใ‚ฉใƒผใ‚ฏใ•ใ‚Œใฆใ„ใ‚‹

+5
โ—‹Issue็ฎก็†

ใ‚ชใƒผใƒ—ใƒณIssueใŒ50ๆœชๆบ€

0/5
โœ“่จ€่ชž

ใƒ—ใƒญใ‚ฐใƒฉใƒŸใƒณใ‚ฐ่จ€่ชžใŒ่จญๅฎšใ•ใ‚Œใฆใ„ใ‚‹

+5
โœ“ใ‚ฟใ‚ฐ

1ใคไปฅไธŠใฎใ‚ฟใ‚ฐใŒ่จญๅฎšใ•ใ‚Œใฆใ„ใ‚‹

+5

Reviews

๐Ÿ’ฌ

Reviews coming soon