Concurrency
183 bites tagged Concurrency — interview questions with model answers, and 60-second explainers.
Strict Two-Phase Locking (S2PL): Safety Over Speed
Strict Two-Phase Locking (S2PL) forces a transaction to hold all its locks until it fully commits or aborts. This prevents cascading aborts in databases but at the cost of concurrency, as other transactions are blocked for longer periods.
MVCC: Read and Write Data Without Blocking Each Other
MVCC avoids slow, traditional locks by giving each transaction its own consistent data snapshot. This allows readers and writers to work at the same time without blocking each other, boosting performance in databases like PostgreSQL.
Database Deadlock: The Two-Way Standoff
A deadlock is a 'Mexican standoff' where two transactions can't finish because each is waiting for a resource the other has locked. This happens in systems with concurrent writes. The database will kill one transaction, forcing your app to handle the retry.
Two-Phase Locking (2PL): Preventing Database Race Conditions
2PL is a database's pessimistic strategy for safe concurrency. A transaction acquires all necessary locks before releasing any, ensuring operations don't clash. It's used to guarantee consistency.
Shared & Exclusive Locks: The Read vs. Write Rule
A Shared (S) lock is like many people reading a library book at once; an Exclusive (X) lock is one person writing in it alone. Databases use S/X locks to manage concurrency, preventing writes from corrupting reads.
Lock Now or Check Later: Optimistic vs. Pessimistic Concurrency
Pessimistic concurrency locks data first, assuming conflict is likely ('ask permission'). Optimistic concurrency proceeds without locks and checks for conflicts before saving, assuming they're rare ('ask forgiveness'). Use pessimistic for high-contention.
Transaction Isolation Levels: The Concurrency vs. Correctness Dial
Think of isolation levels as a database dial trading transaction correctness for raw concurrency. You tune this when balancing performance against the risk of data anomalies. The footgun: the default level isn't always the safest; you must know its guarantees.
Web Workers: Offload Heavy Tasks from the UI Thread
Web Workers run JavaScript on a background thread, preventing heavy tasks from freezing your UI. Use them for complex calculations or data processing that shouldn't block rendering.
Handler and Looper: Android's Threading Backbone
A Looper is a worker that endlessly processes a queue of tasks for a thread. A Handler is how you give that worker a new task from another thread, like updating the UI. The footgun is blocking the main thread's Looper, which freezes your app.
AsyncTask: The Deprecated Way to Do Background Work
AsyncTask was Android's original tool for short background tasks that update the UI. It was used for simple network requests or disk I/O. It's fully deprecated due to memory leaks and lifecycle issues; use Kotlin Coroutines instead.
Threads: Your App's Second Pair of Hands
A thread is a separate path of execution for background work, keeping your app's UI responsive. It's used for long tasks like network calls or disk I/O. The main footgun is trying to update the UI from a background thread, which will crash your app.
Kotlin Coroutines: async/await for Parallel Results
async starts a coroutine for a parallel result, returning a `Deferred` value. `await` pauses until that result is ready. Use it to run independent network calls concurrently. The footgun: using it for sequential tasks creates a needless race condition.
Structured Concurrency in Kotlin
Structured concurrency treats async operations like code blocks: a parent task's lifetime contains its children. In Kotlin, a `CoroutineScope` ensures if the parent is cancelled, all its child coroutines are too.
CoroutineScope: The Parent of Your Coroutines
A CoroutineScope acts as a parent to a group of coroutines, managing their lifecycles. When the parent scope is cancelled, all its children are cancelled too. It's used with builders like `launch` to group related work, like in an Android ViewModel.
Coroutine Dispatchers: Telling Your Coroutines Which Thread to Use
A Dispatcher tells a coroutine which thread or thread pool to use for its work. Use `Dispatchers.Default` for CPU-intensive tasks. If none is specified, it inherits from its parent. The main footgun: `Unconfined` can resume on an unexpected thread.
Get Concurrency bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.