m07-concurrency

Guide safe Rust concurrency design with Arc<Mutex>, channels, and tokio tasks.

Updated Feb 8, 2026
One-click install
npx skills add https://github.com/yumazak/kodo --skill m07-concurrency-yumazak
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: m07-concurrency
Source: https://github.com/yumazak/kodo/tree/main/.agents/skills/m07-concurrency
Command: npx skills add https://github.com/yumazak/kodo --skill m07-concurrency-yumazak

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Concurrency and async reasoning can be error-prone; this skill provides structured guidance to design safe, scalable Rust code that avoids data races and deadlocks.

Core Features & Use Cases

  • Clarifies when to use threads vs async runtimes for CPU-bound vs I/O-bound workloads.
  • Documents common patterns (Arc<Mutex<T>>, Arc<RwLock<T>>, channels, task spawning, cancellation tokens, and structured concurrency) and real-world scenarios.
  • Helps diagnose and prevent common errors like Send/Sync violations, deadlocks, and racing conditions in CLI tools and services.

Quick Start

Describe your concurrency challenge and specify the workload to surface the appropriate safe pattern.

Frequently Asked Questions about m07-concurrency

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent deadlocks and data races in Rust concurrent applications?

To prevent deadlocks and data races in Rust, establish proper locking discipline using patterns like Arc<Mutex<T>> and channels. Ensure Send/Sync correctness and apply structured concurrency to orchestrate tasks and avoid racing conditions.

When should I use Rust threads versus tokio async tasks?

Use Rust threads for CPU-bound multi-threading workloads and tokio async tasks for I/O-bound workloads. Choosing the correct concurrency model ensures safe, scalable task orchestration and prevents runtime bottlenecks.

What is the best way to share state safely across tokio tasks in Rust?

The best way to share state across tokio tasks is using Arc<Mutex<T>> or Arc<RwLock<T>> for controlled access. This pattern enforces thread-safety, Send/Sync correctness, and prevents simultaneous mutable access violations.

How do I fix Send and Sync violations in Rust async runtimes?

Fix Send and Sync violations in Rust by ensuring shared data conforms to Send/Sync bounds and applying proper locking discipline. Restructuring task spawning and using cancellation tokens correctly resolves these thread-safety errors.

Does structured concurrency work well for Rust CLI tools and services?

Structured concurrency works well for Rust CLI tools and services by providing clear task orchestration and error handling. It scopes task lifetimes precisely, ensuring reliable execution and preventing orphaned background tasks.