Concurrency
183 bites tagged Concurrency — interview questions with model answers, and 60-second explainers.
Python Concurrency vs. Parallelism
Concurrency is juggling tasks; parallelism is doing them at once. In Python, use concurrency (threading/asyncio) for I/O-bound work like API calls, and parallelism (multiprocessing) for CPU-bound tasks.
Python's async/await: Concurrent, Not Parallel
async/await lets a single Python thread juggle multiple tasks, pausing one to work on another while it waits for I/O. It's ideal for network requests or database queries. The footgun: it won't speed up CPU-bound tasks, it only helps with waiting.
Python Coroutines: Functions You Can Pause and Resume
A Python coroutine is a function that can be paused and resumed. It yields control during I/O waits, allowing other tasks to run instead of blocking the program. The main footgun: calling an `async` function does nothing; you must `await` it to run it.
SharedArrayBuffer: True Shared Memory for JS Threads
SharedArrayBuffer is a shared whiteboard for JS threads, letting them access the same memory without slow data copies. It's used for high-performance parallel tasks. The footgun: without `Atomics` to coordinate, you'll get race conditions and corrupted data.
Node.js Cluster: Scaling on a Single Machine
The `cluster` module turns a single-threaded Node.js app into a multi-process server that uses all CPU cores. It's ideal for scaling network applications on one machine by sharing a single port.
Worker Threads: True Parallelism in Node.js
Worker threads give Node.js a separate brain for heavy lifting, letting you run CPU-intensive code without blocking the main event loop. Use them for tasks like image processing, not I/O. The footgun is assuming memory is shared; it isn't.
Node.js Child Processes: Escaping the Main Thread
A child process lets your Node.js app run external commands without blocking the event loop. Use it for CPU-intensive tasks like image processing or running system utilities. The footgun: using synchronous versions (`execSync`) will block your entire server.
The Node.js Event Loop: Concurrency on a Single Thread
The Node.js event loop lets a single thread handle high concurrency by offloading I/O. It's ideal for web servers and APIs, but the footgun is that any long-running synchronous code will block the entire application, freezing all other requests.
Main Thread Checker: Keep Your UI Responsive
The Main Thread Checker is an Xcode tool that catches UI updates on background threads, which cause crashes or glitches. It runs during debugging, flagging AppKit, UIKit, or SwiftUI calls made off the main thread.
Grand Central Dispatch (GCD): Your App's Task Manager
Grand Central Dispatch (GCD) is your app's task manager, letting you run code in the background without freezing the UI. Use it to offload network requests or heavy computations, then update the UI on the main queue.
TaskGroup: Dynamic, Structured Concurrency in Swift
A TaskGroup is like a manager for parallel jobs. You add a dynamic number of tasks, and it runs them concurrently, ensuring the parent task waits for them all. Use it to fetch multiple images or API data.
AsyncSequence: A Sequence That Awaits Its Next Element
AsyncSequence is like a regular Swift Sequence, but you `await` its next element. It lets you process values that arrive over time, like network data, without blocking. The footgun: iteration suspends, so run it in a `Task` for true concurrency.
MainActor: Keep Your UI on the Main Thread
The MainActor is a global actor ensuring code runs on the main thread, the only safe place for UI updates. Use it when modifying UIKit or SwiftUI views. The footgun is over-applying it to a whole class, which can serialize background work and freeze the.
async/await: Write Concurrent Code That Reads Synchronously
async/await lets you write asynchronous code that reads like a synchronous story, eliminating callback hell. It's ideal for network requests or file I/O. The footgun is thinking `await` blocks a thread; it only suspends the current task.
Rust's Fearless Concurrency: Catch Bugs Before They Ship
Rust's "fearless concurrency" uses the ownership and type system to turn data races into compile-time errors. This allows you to safely use threads, message passing, or shared state without runtime surprises. The footgun is assuming this prevents all bugs.
Go's Worker Pool Pattern: Capping Concurrency
A worker pool caps concurrency by using a fixed number of goroutines to process jobs from a queue. Use it for rate-limiting API calls or processing files without spawning unlimited goroutines.
Go Execution Tracer: Pinpointing Concurrency Bottlenecks
Go's Execution Tracer creates a visual timeline of your program, capturing goroutine state changes, syscalls, and GC events. It's essential for diagnosing subtle concurrency issues like lock contention. The main footgun is misusing annotations for work.
Go's `context` Package: Propagating Cancellation and Deadlines
Go's `context` package is a lifeline for requests, carrying cancellation signals, deadlines, and values across function calls and goroutines. It's essential for I/O-bound operations to prevent resource leaks.
Go's Time: Wall Clocks vs. Monotonic Clocks
Go separates telling time (wall clock) from measuring it (monotonic clock) to prevent errors from system clock changes. Use `time.Sub` for reliable timing and `time.Format` for display. The footgun: formatting uses a magic date, not YYYY-MM-DD.
Go's Race Detector: Find Concurrency Bugs at Runtime
The Go race detector finds data races by watching memory access at runtime. Use `go test -race` in CI or on a canary instance, but remember: it only catches races that actually execute. If your tests don't trigger the race, it won't be found.
Rust's Scoped Threads: Borrowing Across Threads Safely
Scoped threads let you borrow local variables from a parent thread without complex wrappers. The scope guarantees all spawned threads are joined before it exits, satisfying the borrow checker. Use it to parallelize work on stack data.
Go's Memory Model: Don't Be Clever
Go guarantees your program behaves predictably—as if on one CPU—if you prevent data races. Use channels or `sync` primitives to serialize access when goroutines share data. The footgun is relying on timing instead of explicit synchronization.
Send vs. Sync: Rust's Thread Safety Contracts
Send means a value can move to another thread; Sync means references to it can be shared. They are the compiler's contracts for preventing data races. The compiler checks them when you spawn threads.
Rust's `std::sync::Mutex`: Guarding Shared Data
A Rust `Mutex` guards shared data, granting access only via a temporary RAII "guard" that auto-releases the lock. It's used inside an `Arc` for safe multi-threaded mutation.
Get Concurrency bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.