concurrent

Concurrent -- Concurrency & Parallelism

Activate When

• User invokes /godmode:concurrent
• User says "thread safety", "race condition", "deadlock", "lock-free"
• User says "async/await", "actor model", "parallelism", "concurrent"
• User says "mutex", "semaphore", "channel", "goroutine", "tokio"
• When building multi-threaded or async systems
• When /godmode:review flags potential race conditions or deadlocks
• When /godmode:test reveals non-deterministic test failures

Workflow

Step 1: Concurrency Context Assessment

Understand the concurrency requirements before designing solutions:

CONCURRENCY CONTEXT:
Project: <name and purpose>
Language/Runtime: <Go | Rust | Node.js | Python | Java | Erlang/Elixir>
Concurrency Model: Threads | Green Threads | Event Loop | Actor Model | CSP
Current Issues: <race conditions, deadlocks, performance bottlenecks, none>
Shared State: <what mutable state is shared across concurrent units>
I/O Profile: CPU-bound | I/O-bound | Mixed
Scale: <concurrent connections/operations expected>
  ...

If the user has not provided context, ask: "What language/runtime are you using, and is the workload primarily CPU-bound or I/O-bound? This determines the right concurrency model."

Step 2: Thread Safety Analysis

Identify shared mutable state and classify access patterns:

SHARED STATE INVENTORY:
| State | Access Pattern | Protection | Risk |
|--|--|--|--|
| <variable/resource> | Read-Write | <mutex/none> | HIGH |
| <variable/resource> | Read-Only | None needed | LOW |
| <variable/resource> | Write-Only | <channel> | MED |

CRITICAL SECTIONS:
  ...

Rules:

• Identify every piece of shared mutable state before writing any concurrent code
• Prefer immutable data and message passing over shared mutable state
• If shared mutable state is unavoidable, protect it with the narrowest possible lock scope
• Document every critical section and its invariants

Step 3: Race Condition Detection

Systematically check for race conditions: