rust-concurrency_skill

This skill helps Rust engineers diagnose, design, and optimize concurrent and async code, ensuring thread safety, deadlock prevention, and efficient runtime
  • Shell

20

GitHub Stars

3

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill huiali/rust-skills --skill rust-concurrency

  • SKILL_EN.md2.0 KB
  • SKILL_ZH.md2.5 KB
  • SKILL.md8.3 KB

Overview

This skill is a Rust concurrency and async programming expert that diagnoses, designs, and optimizes concurrent code. It focuses on Send/Sync rules, threads vs async, synchronization primitives (Mutex, RwLock, Arc, atomics), channels, deadlock prevention, and race condition debugging. It helps choose models, apply patterns, and verify thread safety in real projects.

How this skill works

The skill inspects code and design choices to recommend the appropriate concurrency model (threads, async/await, or hybrid). It analyzes types for Send/Sync bounds, suggests synchronization primitives, detects common anti-patterns (locks across await, inconsistent lock ordering), and proposes fixes or refactors. It also generates checks and commands for testing with miri, loom, and sanitizers.

When to use it

  • Choosing between threads and async for an I/O- or CPU-bound workload
  • Refactoring shared mutable state to remove data races or reduce contention
  • Diagnosing compilation errors like E0277 (Send/Sync) and mutex-related panics
  • Reviewing code for deadlock risks and lock-ordering violations
  • Designing task spawning, timeouts, and cancellation strategies for async systems

Best practices

  • Prefer threads (or rayon) for CPU-parallel workloads and async runtimes (tokio/async-std) for I/O-bound tasks
  • Use Arc + Mutex/RwLock for shared ownership; replace Rc with Arc for cross-thread use
  • Keep lock scopes minimal and never hold MutexGuard across await points
  • Establish consistent lock ordering and document it to avoid deadlocks
  • Favor atomics for simple counters/flags and message passing for decoupled components

Example use cases

  • Convert a blocking HTTP client into async tokio tasks with timeouts and cancellation
  • Fix Send/Sync compile errors by identifying non-Send fields and replacing Rc with Arc
  • Design a producer/consumer pipeline using mpsc channels to avoid shared-state locks
  • Reduce contention on a shared cache by switching to Arc<RwLock<T>> for read-heavy workloads
  • Write tests with loom or thread sanitizer to reproduce and fix subtle race conditions

FAQ

Use threads for CPU-bound parallelism and async/await for high-concurrency I/O workloads. For mixed workloads, run CPU tasks inside async via spawn_blocking.

Why am I getting E0277 Send not satisfied?

A type contains non-Send fields (Rc, raw pointers, non-atomic types). Inspect all fields, replace Rc with Arc, or wrap non-Send data so it does not cross thread boundaries.

How can I avoid deadlocks when using multiple locks?

Establish and follow a consistent global lock ordering, minimize lock duration, and avoid holding locks across await points. Consider redesigning with message passing or atomics when possible.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
rust-concurrency skill by huiali/rust-skills | VeilStrat