Concurrency
183 bites tagged Concurrency — interview questions with model answers, and 60-second explainers.
Rust Async Runtimes: The Engine for `async/await`
Rust's `async/await` is just syntax; an async runtime like Tokio is the engine that runs the code. It polls `Future`s until they complete, managing I/O and scheduling. This is essential for web servers.
Rust's async/await: Cooperative Concurrency
Rust's async/await is cooperative concurrency, where tasks explicitly yield control with `.await`. This is ideal for I/O-bound work like managing thousands of network connections. The biggest footgun: calling an `async` function without `.await` does nothing.
Go Channels: Buffered vs. Unbuffered
Unbuffered channels are a synchronous rendezvous, blocking until both sender and receiver are ready. Buffered channels are an async mailbox, letting senders drop messages and go. The footgun is using a buffer to hide a deadlock instead of fixing it.
Rust Channels: Thread-Safe Communication
Rust channels are like a thread-safe conveyor belt for sending data between threads. Use them to pass work to workers or aggregate results. The footgun: the receiver blocks forever if any sender isn't dropped, as the channel only closes when all senders are…
Rust's std::thread::spawn: Create and Manage OS Threads
std::thread::spawn creates a new OS thread to run code concurrently, returning a JoinHandle to wait for completion. Use it for background tasks or parallel computations. The footgun: dropping the handle detaches the thread, risking resource leaks.
Rust Marker Traits: Properties as Types
Marker traits are empty labels telling the Rust compiler about a type's capabilities, like being copyable or thread-safe. They have no methods; their presence is the signal. They're key for concurrency (`Send`/`Sync`) and memory (`Copy`/`Sized`) safety checks.
Go's Panic/Recover: For Exceptional Errors Only
Go's panic/recover is a last-resort error mechanism, not a try/catch replacement. A panic unwinds a goroutine's stack until a recover in a defer'd function catches it. It's used to keep a server alive when one request fails catastrophically.
Go's GC: Low-Latency Collection with Tri-color Marking
Go's GC uses a tri-color algorithm to find unused memory concurrently, avoiding long pauses. It's crucial for low-latency services. The main footgun is breaking the invariant: a 'finished' (black) object must never point to a new (white) one without notifying…
Rust's Arc<T>: Share Data Ownership Across Threads
Rust's `Arc<T>` lets multiple threads share ownership of heap data. It's a smart pointer that counts references atomically. Use it for shared caches or config. The footgun: `Arc` only makes sharing safe, not mutation—you still need a `Mutex` for that.
Go's sync.Map: A Specialized Concurrent Map
Go's `sync.Map` is a concurrent map optimized for keys written once and read many times. It's ideal for long-lived caches, but it's not a generic replacement for a map with a mutex. The footgun is using it for frequent writes, which can be slower.
Goroutines
A goroutine is a lightweight function managed by Go's own runtime scheduler rather than the operating system, letting a single program run hundreds of thousands of concurrent tasks cheaply instead of the handful an OS thread model allows.
Flutter's `compute`: Offload Heavy Work from the UI Thread
Flutter's `compute` function runs heavy calculations in the background to prevent your app's UI from freezing. Use it for tasks like parsing large JSON or complex math. The footgun: on the web, it runs on the same event loop, not in a true parallel thread.
Background Execution and Services in Flutter
Think of background execution as a helper doing heavy lifting off-screen. It keeps your app's UI smooth by running tasks like data processing on a separate thread (Isolate). The footgun is that isolates don't share memory; you must pass data explicitly.
Dart Isolates: True Parallelism Without Shared Memory
Dart isolates provide true parallelism by running code in a separate thread with its own memory. Use them to offload heavy tasks like parsing huge JSON files or complex calculations that would otherwise freeze your Flutter UI.
Future.wait: Run Concurrent Dart Operations
Run multiple async operations concurrently and collect their results in a single list. Use it to fire off independent tasks, like multiple network requests, and wait for them all to finish. The footgun: if one future fails, you lose all results by default.
The Dart Event Loop: Your App's Task Manager
The event loop is Dart's single-threaded task manager. It processes one event at a time from a queue (like user taps or network responses), preventing the UI from freezing. Use `async`/`await` to avoid blocking it with long operations.
Dart's async/await: Non-Blocking Code That Reads Synchronously
Dart's `async`/`await` makes non-blocking code read like a simple script. Use it for network requests or file I/O to keep your UI from freezing. The biggest footgun is calling an async function but forgetting to `await` its `Future` result.
Phantom Reads: When New Rows Appear Mid-Transaction
A phantom read occurs when a transaction repeats a query and finds new rows that match its search criteria, inserted by another committed transaction. It's common in reporting jobs that need a stable set of data.
Causal Consistency: A Memory Model for Concurrency
Causal consistency is a rulebook for concurrent systems, defining legal data access patterns. It's used to ensure correctness in distributed shared memory and transactions, preventing data corruption from simultaneous operations.
Vector Clocks: Tracking Causality in Distributed Systems
A vector clock is an array of counters, one for each node, that tracks causality across a distributed system. It's how databases resolve conflicting writes.
Serializable Snapshot Isolation: True Serializability Without Heavy Locking
SSI upgrades Snapshot Isolation to true serializability. It optimistically lets transactions run, but aborts one if a dangerous read-write dependency arises. This prevents subtle data corruption in systems like PostgreSQL without heavy locking.
Write Skew: The Phantom Anomaly of Snapshot Isolation
Write skew is when two transactions read the same data, make decisions, and then update *different* data, violating a business rule. It's common in booking systems or when enforcing multi-row constraints under Snapshot Isolation.
Snapshot Isolation: A 'Photo' of Your Database
Snapshot Isolation gives a transaction a private 'photo' of the database from when it started, ensuring consistent reads. It's used in high-concurrency systems to prevent readers from blocking writers. The footgun is that it doesn't prevent all anomalies.
Timestamp Concurrency Control: No Locks, Just Time
Timestamp-based concurrency control bets that transaction conflicts are rare, using timestamps to order operations instead of locking data. It's used where lock overhead is high, but the footgun is that frequent conflicts can cause transaction starvation.
Get Concurrency bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.