| 1. Concurrency Models & Runtime Fundamentals | 5/5 | 5/5 | 5/5 | 3/5 | 4/5 | For interviews: state plainly whether the language's default concurrency unit gives real CPU parallelism (Java, Kotlin, Go: yes; Python threading, JS main thread: no) before reaching for any pattern -- it's the fastest way to signal you understand what you're actually being asked to design. |
| 2. Locks, Mutexes & Synchronized Access | 5/5 | 5/5 | 4/5 | 3/5 | 2/5 | Default to the language's built-in lock (synchronized/ReentrantLock, Mutex, sync.Mutex, Lock/RLock) and always release it in a finally/defer/with/try-finally-equivalent; only Go gives you a safety net (deadlock crash-and-dump) if you get lock ordering wrong, so discipline about consistent lock-acquisition order matters most in Java, Kotlin, and Python. |
| 3. Condition Variables, Waiting & Signaling | 4/5 | 4/5 | 4/5 | 4/5 | 3/5 | Reach for the language's built-in condition variable (wait/notify+Condition, Condition, sync.Cond) only when a channel/Promise-shaped primitive genuinely doesn't fit; when it's available, prefer Channel (Kotlin/Go) or Promise (JS) since they eliminate the spurious-wakeup and notify-target bug classes by construction. |
| 4. Atomics, volatile & the Memory Model | 4/5 | 5/5 | 5/5 | 3/5 | 3/5 | Java/Kotlin and Go both give you a real, separately-documented memory model to reason from precisely -- lean on that rigor rather than intuition for any question involving unsynchronized access. Treat Python's GIL and JS's single-threadedness as removing most, not all, of this category of bug, and always ask explicitly whether a compound operation (not just a single read/write) is involved before declaring something 'safe without a lock'. |
| 5. Thread Pools, Executors & Structured Concurrency | 4/5 | 5/5 | 5/5 | 3/5 | 3/5 | For CPU-bound work, Java/Kotlin/Go give you real parallelism with the language's default primitive; Python and Node both require an explicit escape hatch (processes or worker threads) and neither language provides a Java-style named backpressure/rejection policy, so build that discipline in yourself with a Semaphore or bounded queue. |
| 6. Async/Await, Futures & Non-Blocking I/O | 5/5 | 5/5 | 5/5 | 3/5 | 4/5 | State explicitly whether the language's async model is 'colored' (suspend/async keywords propagate through signatures: Kotlin, Python, JS) or 'uncolored' (ordinary blocking-looking code scales anyway: Go always, Java only inside virtual threads) -- it changes how you reason about where interleaving is even possible in a given codebase. |
| 7. Channels & Message-Passing Concurrency | 5/5 | 2/5 | 5/5 | 3/5 | 2/5 | If channels are central to your design, Go and Kotlin give you the most complete, first-class support (select, close, capacity semantics); in Java or Python, be ready to explicitly name the workaround (poison pills, poll-based multiplexing) rather than assuming an equivalent exists. |
| 8. Cancellation, Timeouts & Context Propagation | 4/5 | 3/5 | 5/5 | 4/5 | 3/5 | Structured-concurrency languages (Kotlin, and Python's asyncio to a lesser extent) give you automatic propagation almost for free; Go and JS require disciplined manual threading of ctx/AbortSignal through every layer; Java's classic Future.cancel API requires you to remember it's a two-step process (stop waiting, then separately cancel) that StructuredTaskScope only recently fixed. |
| 9. Concurrent Collections, Shared State & Debugging Tools | 5/5 | 4/5 | 4/5 | 3/5 | 4/5 | If Go is on the table for a CPU/concurrency-heavy service, mention -race explicitly -- it's the single most differentiated piece of tooling in this whole manual. Otherwise, default to each language's native concurrent-collection type over a plain one guarded by hand, and know your production stack-dump tool (jstack, goroutine SIGQUIT dump, py-spy, Node's diagnostic report) before you need it under pressure. |