← ClaudeAtlas

dotnet-techne-csharp-concurrency-patternslisted

Use when choosing .NET concurrency patterns for async I/O, queues, pipelines, or thread safety. Keywords: async/await, channels, dataflow, Rx, lock contention, producer consumer, parallel processing.
Metalnib/dotnet-episteme-skills · ★ 11 · Data & Documents · score 75
Install: claude install-skill Metalnib/dotnet-episteme-skills
# .NET Concurrency: Choosing the Right Tool ## When to Use This Skill Use this skill when: - Deciding how to handle concurrent operations in .NET - Evaluating whether to use async/await, Channels, Dataflow, or other abstractions - Tempted to use locks, semaphores, or other synchronization primitives - Need to process streams of data with backpressure, batching, or debouncing - Managing state across multiple concurrent entities ## Reference Files - [advanced-concurrency.md](advanced-concurrency.md): TPL Dataflow, Reactive Extensions, hosted worker state patterns, and async local function patterns ## The Philosophy **Start simple, escalate only when needed.** Most concurrency problems can be solved with `async/await`. Only reach for more sophisticated tools when you have a specific need that async/await can't address cleanly. **Try to avoid shared mutable state.** The best way to handle concurrency is to design it away. Immutable data, message passing, and isolated state (like actors) eliminate entire categories of bugs. **Locks should be the exception, not the rule.** When you can't avoid shared mutable state: 1. **First choice:** Redesign to avoid it (immutability, message passing, single-consumer isolation) 2. **Second choice:** Use `System.Collections.Concurrent` (ConcurrentDictionary, etc.) 3. **Third choice:** Use `Channel<T>` to serialize access through message passing 4. **Last resort:** Use `lock` for simple, short-lived critical sections --- ## Decision Tre