메뉴
Load before any concurrency review. Required by the concurrency-reviewer agent — covers race conditions, deadlocks, resource leaks, shared state misuse, synchronisation primitives, and cancellation propagation across JavaScript/TypeScript, Python, Java, C#, C++, Go, and Rust.
Load before planning or routing any task. Required by mission-control — maps task archetypes to ordered sequences of specialist agents, with handoff context and success criteria for each step.
Load before reviewing any phase. Required by all internal reviewer agents — covers adversarial review philosophy, the approve/reject verdict contract, and escalation policy.
Load when operating as a sub-agent invoked via the agent tool — covers handoff mode detection, autonomous execution, clarification protocol, and the minimum completion report contract.
Load before running a comprehensive review. Covers scope resolution, pre-flight tool checks, parallel specialist dispatch, synthesis, and output format.
Recipe reference for installing tools in the container environment. Used by bootstrap and specialist reviewer agents to look up the correct install command for any tool.
Load before any API or CLI interface review. Required by the api-reviewer agent — covers REST naming, HTTP semantics, error consistency, breaking changes, CLI conventions, pagination, auth, and a three-tier severity model.
| name | concurrency-review |
| description | Load before any concurrency review. Required by the concurrency-reviewer agent — covers race conditions, deadlocks, resource leaks, shared state misuse, synchronisation primitives, and cancellation propagation across JavaScript/TypeScript, Python, Java, C#, C++, Go, and Rust. |
| license | AGPL-3.0-or-later |
| allowed-tools | read |
Concurrency bugs are among the hardest to reproduce and diagnose. They appear under load, disappear under a debugger, and often produce silent data corruption rather than obvious crashes. Every section below states the language-agnostic principle first, then gives language-specific signals.
A race condition occurs when two or more concurrent units (goroutines, threads, async tasks) access the same memory location concurrently, and at least one access is a write, without synchronisation.
What to look for — universal signals:
counter++ is not atomic in most languages even for primitive types.Language-specific signals:
async functions read and update the same module-level state between await points without coordination. worker_threads or SharedArrayBuffer code introduces true shared-memory races unless Atomics or message passing is used correctly.threading.Thread or asyncio tasks sharing mutable state without a threading.Lock or other coordination. The GIL protects many built-in operations but not multi-step compound operations such as read-modify-write on a dict.HashMap modified and read from multiple threads without ConcurrentHashMap or synchronisation. ++ on a shared int field without AtomicInteger or synchronized.List<T> or Dictionary<TKey, TValue> accessed from multiple tasks or threads without lock, ConcurrentDictionary, or Interlocked. Task.Run closures capturing mutable loop variables are a repeat offender.std::vector, raw pointers, or shared structs accessed from multiple std::thread instances without std::mutex or std::atomic. Concurrent unsynchronised access to the same memory location is undefined behaviour, even when it seems to work in tests.item in go func() { process(item) }() inside a range loop. Detection: go test -race ./...Arc<Mutex<T>> or Arc<RwLock<T>> shared across tasks with ad-hoc interior mutability, static mut, or unsafe FFI access that bypasses the compiler's usual guarantees.A deadlock occurs when two or more concurrent units are each waiting for the other to release a resource, resulting in all of them blocking indefinitely.
What to look for — universal signals:
Language-specific signals:
threading.Lock acquired twice from the same thread without threading.RLock. asyncio coroutines awaiting each other in a cycle also hang permanently.synchronized blocks on two objects acquired in opposite order from two threads. Object.wait() called without holding the object's monitor.lock statements acquired in opposite order across tasks or threads. Blocking on .Result or .Wait() while the awaited continuation needs the same context can deadlock UI or request threads.std::mutex instances acquired in inconsistent order, or std::condition_variable::wait used without a predicate so a notification is missed and the thread sleeps forever.sync.Mutex is not re-entrant — a goroutine holding a mutex that calls a function which tries to acquire the same mutex will deadlock. Unbuffered channel send with no goroutine ready to receive, or vice versa.std::sync::Mutex guard across a call that tries to re-lock the same mutex, or awaiting while holding a Tokio mutex guard needed by another task.A resource leak occurs when a concurrent unit starts but never terminates, or when a resource acquired for concurrent use is never released.
What to look for — universal signals:
Language-specific signals:
setInterval handles never cleared, or Worker threads started without a termination path.threading.Thread with no daemon flag and no join() — Python waits for all non-daemon threads before exit. asyncio.Task created with asyncio.create_task() and not awaited or cancelled.ExecutorService created but shutdown() or shutdownNow() never called — the JVM cannot exit. Thread started but interrupt() is never called and the thread has no exit condition.Task.Run work with no CancellationToken, Timer instances never disposed, or IAsyncDisposable resources abandoned in background services.std::thread work with no ownership or shutdown path, or threads waiting on queues that are never signalled during shutdown.go func() { ... }() with no context.Context, no done channel, and no cancellation signal. A goroutine reading from a channel nobody will ever close or write to. wg.Add(1) without a corresponding defer wg.Done() inside the goroutine.Accessing shared state incorrectly produces data corruption that may not surface immediately.
What to look for — universal signals:
Language-specific signals:
await points, or Worker threads mutating shared buffers without Atomics.dict or list modified from multiple threads. Individual dict operations are often GIL-protected, but compound operations such as check-then-set are not.ArrayList or HashMap used in place of CopyOnWriteArrayList or ConcurrentHashMap in concurrent code.List<T> or Dictionary<TKey, TValue> used where ConcurrentBag<T> or ConcurrentDictionary<TKey, TValue> is required, or a read-modify-write cycle occurs outside a lock.std::vector, std::map, or shared raw memory modified concurrently without a lock, or std::atomic used for one field while adjacent non-atomic fields still race.map read and written from multiple goroutines without a sync.RWMutex or sync.Map. Slice appended to from multiple goroutines concurrently.RefCell, Mutex, RwLock) used to share state across tasks without a clear ownership model, or unsafe shared state crossing thread boundaries.Using the wrong synchronisation primitive, or misusing the correct one, introduces bugs that are as harmful as not synchronising at all.
What to look for — universal signals:
Language-specific signals:
await points, use a well-understood serialisation pattern. Shared state between Workers must use SharedArrayBuffer with Atomics for safe concurrent access.threading.Lock vs threading.RLock — use RLock when the same thread may acquire the lock recursively. threading.Semaphore vs threading.BoundedSemaphore — prefer BoundedSemaphore to catch release-without-acquire bugs.synchronized on a local variable has no effect because each caller gets its own lock. volatile provides visibility, not atomicity, so it does not protect a compound read-modify-write.lock, SemaphoreSlim, Monitor, and Interlocked deliberately. Using lock for simple counters or Interlocked for multi-step state transitions is the wrong trade-off.std::mutex, std::shared_mutex, std::condition_variable, and std::atomic deliberately. Copying lock-owning types, or mixing atomics with non-atomic reads of the same state, is a correctness bug.sync.Mutex passed or embedded in a struct by value — use pointer receivers or pass by pointer. For read-heavy access, sync.RWMutex may be appropriate; for simple counters, sync/atomic is usually clearer.std::sync::Mutex, RwLock, atomics, and async-aware primitives carefully. Using a blocking mutex inside async code, or holding a lock guard across .await, is a common mistake.Message-passing concurrency has its own failure modes distinct from shared-memory concurrency.
What to look for — universal signals:
Language-specific signals:
await on a spawned async operation, or a Worker message protocol with no timeout or shutdown path.asyncio.Queue.join() without matching task_done() calls blocks forever. Thread-safe queues need explicit sentinel values or shutdown signalling.BlockingQueue.put() with no timeout blocks indefinitely if the queue is full. Future.get() with no timeout blocks indefinitely if the task never completes.Channel<T> readers awaiting forever because writers are never completed, or Task.WhenAll waiting on fire-and-forget tasks that never settle.std::condition_variable::wait without a predicate risks missed wake-ups, and producer-consumer queues with no shutdown sentinel leave consumers blocked forever.for v := range ch) that is never closed blocks forever. nil channel in a select case is silently ignored and can mask bugs.SETNX-style Redis locks have split-brain failure modes: the lock holder may have died without releasing, and a new holder is elected before the first holder's operations complete.A concurrent unit that cannot be told to stop is a resource leak and a graceful shutdown problem.
What to look for — universal signals:
Language-specific signals:
AbortController or AbortSignal not passed to fetch or other cancellable APIs, or timers and Worker threads not cleaned up when the surrounding request or job is cancelled.asyncio task cancellation raises CancelledError; catching and suppressing it prevents cancellation from propagating. threading.Event used to signal threads to stop but not checked inside blocking waits.Future.cancel(true) does not interrupt the thread unless the task checks Thread.interrupted(). ExecutorService tasks that block on I/O must use interruptible I/O or check the interrupted flag.CancellationToken accepted at the API boundary but not passed to downstream Task work, I/O calls, or retry loops.std::jthread or std::stop_token support ignored, or custom stop flags checked only before entering a long blocking wait.context.Context not passed to goroutines or external calls. ctx.Done() not checked in long-running loops. context.Background() used where a child context derived from the request context was appropriate.select! on the shutdown signal or ignore it inside long-running loops.async void: exception propagation is lost — exceptions thrown in async void methods escape normal task handling; prefer Task or Task<T> so callers can observe failures..Wait() / .Result in synchronous contexts can deadlock when the awaited work needs to resume on the same captured context.ConfigureAwait(false) in reusable library code can cause surprising context capture in callers that still use a synchronisation context.lock on this, a public field, or typeof(T) exposes the lock object to external code and invites deadlocks.std::thread detached without a clear lifetime owner creates shutdown leaks and hidden races. Prefer joinable ownership such as std::jthread where available.std::mutex or std::atomic is undefined behaviour, even when the code appears stable under light load.std::condition_variable waits must always use a predicate to handle spurious wake-ups correctly.Arc<Mutex<T>> lock poisoning ignored: if a thread panics while holding a Mutex, subsequent .lock() calls return Err; blindly unwrapping hides the original failure mode.std::thread::sleep inside tokio::spawn starves the async executor — use tokio::task::spawn_blocking for blocking or CPU-bound work.async-trait heap allocation: every async fn in a trait compiled via async-trait allocates a Box<dyn Future> — this is a hot-path concern in high-throughput code.| Language | Tool | Command |
|---|---|---|
| JavaScript and TypeScript | ESLint promise rules | eslint . --rule 'promise/catch-or-return:error' --rule '@typescript-eslint/no-floating-promises:error' |
| Python | Ruff | ruff check . |
| Java | SpotBugs | mvn spotbugs:check or gradle spotbugsMain |
| C# | Roslyn analysers | dotnet build |
| C++ | ThreadSanitizer | build and run with -fsanitize=thread |
| Go | Race detector (built-in) | go test -race ./... |
| Rust | Clippy and compiler checks | cargo clippy -- -W clippy::await_holding_lock |
Race detector output (Go) and ThreadSanitizer findings (C++) are automatic Blocking findings. SpotBugs threading findings (Java) are Blocking or Recommendation depending on the specific rule.
Concurrency error that will cause data corruption, crashes, or deadlock under concurrent load. A race detector finding is always Blocking.
Examples: unprotected shared map write; lock ordering violation; goroutine/thread started with no exit condition in a long-lived service; channel closed from receiver side.
Concurrency code that is correct under current conditions but brittle or likely to fail under different load or usage patterns.
Examples: shared read-heavy map using exclusive lock where RWMutex would suffice; missing timeout on a blocking call that is unlikely but possible to hang; cancellation signal accepted but not checked inside a long loop.
Minor quality issue or use of a suboptimal but functionally correct primitive.
Examples: sync.Mutex where sync.Once is the idiomatic choice; BoundedSemaphore preferred over Semaphore; a concurrent unit that could be simplified to a sequential one.