Search
27 results for “locking”
Search results
Database Locking & Deadlocks
How PostgreSQL's row-level lock modes actually differ in strength, why it can't predict which transaction a deadlock will abort, and why acquiring locks in a consistent order is the real fix, not a "nice to have".
Why does calling a blocking function inside an async function defeat the purpose of using asyncio?
A blocking call (synchronous file I/O, a synchronous HTTP request, `time.sleep`) occupies the single thread the event loop runs on, and unlike `await`, it does not yield control back, the entire event loop is frozen for the duration of that blocking call, so every other coroutine that could otherwise be making progress is stalled too. This is why async code requires async-compatible libraries throughout the I/O path; a single accidental blocking call anywhere in a hot path can silently serialize what was supposed to be concurrent work, and the bug often doesn't show up until real concurrent load exposes it.
What is the practical difference between SELECT ... FOR UPDATE and SELECT ... FOR SHARE?
FOR UPDATE takes an exclusive row lock, it blocks other transactions from updating, deleting, or taking any competing lock (including another FOR UPDATE or FOR SHARE) on the same rows, appropriate when you're about to modify the row and need to ensure nothing else changes or locks it first. FOR SHARE takes a shared lock, it still blocks updates and deletes, but permits other transactions to also take FOR SHARE or FOR KEY SHARE locks on the same rows concurrently, appropriate when you only need to ensure a row doesn't change or get deleted while you read it, without needing exclusive access.
PostgreSQL detects a deadlock between two transactions. What does it actually do, and can you predict which transaction survives?
PostgreSQL automatically detects the circular wait (a deadlock) and resolves it by aborting one of the involved transactions, letting the other(s) proceed. The documentation is explicit that which transaction gets aborted is difficult to predict and shouldn't be relied upon, there is no guarantee it's the "smaller" transaction, the one that started the wait, or any other predictable rule. Applications need to handle a deadlock-abort the same way they'd handle a serialization failure: catch it and retry the aborted transaction, rather than assuming a specific transaction will always be the one sacrificed.
Two transactions each update two of the same two accounts, but in opposite order, and deadlock. What's the actual fix, not just for this pair of transactions, but for the application generally?
The deadlock happens because Transaction 1 locks account A then waits for account B, while Transaction 2 locks account B then waits for account A, a circular wait. The general fix isn't retry logic alone, retries only paper over deadlocks that keep recurring, it's acquiring locks on multiple objects in the same, consistent order everywhere in the application (for example, always locking accounts in ascending id order), which makes the circular-wait pattern structurally impossible rather than merely less frequent. Retry logic is still worth having as a safety net, but consistent lock ordering is what actually eliminates this class of deadlock.
Python Async Programming
How asyncio's single-threaded event loop achieves concurrency without threads, why blocking calls silently defeat it, and when async actually helps versus when it's pure overhead.
What's the practical difference between Repeatable Read and Serializable, given that PostgreSQL's Repeatable Read already prevents phantom reads?
PostgreSQL's Repeatable Read goes beyond the SQL standard's minimum and already prevents phantom reads via snapshot isolation, but it can still allow a specific class of anomaly called a serialization anomaly, where the combined effect of several concurrently-committed transactions is not equivalent to any possible serial (one-at-a-time) ordering of them, even though each transaction individually looks consistent. Serializable adds predicate locking on top of snapshot isolation specifically to detect and prevent that remaining anomaly, guaranteeing that the outcome is always equivalent to transactions having run one at a time in some order. The cost is the same as Repeatable Read's, more serialization failures the application must retry, in exchange for the strongest correctness guarantee available.
When does asyncio actually help, and when is it not worth the added complexity?
asyncio helps specifically for I/O-bound workloads with many concurrent operations, handling thousands of simultaneous network connections, making many concurrent API calls, where most of the time is spent waiting, not computing. It does not help CPU-bound work at all, since the event loop is still single-threaded and a CPU-heavy coroutine blocks everything else exactly like any other blocking call; CPU-bound work needs `multiprocessing` or a separate process pool instead. For a workload with low concurrency or that's primarily CPU-bound, asyncio adds real complexity (colored functions, async-compatible libraries everywhere) without a corresponding benefit.
Why does the choice between WSGI and ASGI matter when picking a Python web framework?
WSGI (Web Server Gateway Interface) is the traditional, synchronous interface between Python web applications and servers, one request is handled by one worker thread/process at a time, blocking for its duration. ASGI (Asynchronous Server Gateway Interface) extends that to support async request handling and other async protocols (WebSockets), letting a single worker handle many concurrent requests while they're waiting on I/O, the same underlying model as asyncio generally. Flask and Django historically are WSGI (Django has gained ASGI support); FastAPI is ASGI-native. The choice matters because it determines whether the framework can actually benefit from async I/O concurrency, or whether it's fundamentally a one-request-per-worker model regardless of async syntax used inside a handler.
Why is storing Terraform state locally a problem for a team, and what is the standard fix?
Local state is a single file on one person's machine, a second engineer running `terraform apply` has no idea what the first one already created, so both can independently "discover" no matching state and try to recreate resources, or worse, apply conflicting changes concurrently with no locking. The standard fix is a remote backend (S3+DynamoDB, Terraform Cloud, GCS, Azure Blob) that stores state centrally and supports locking, so only one apply can run at a time and everyone reads the same source of truth.
Linux Processes & Networking: Monitoring, Signals, Ports, and Connectivity
How Linux Runs, Communicates, and Stays Alive.
Why are IAM roles preferred over long-lived access keys for workloads running on EC2 or Lambda?
A long-lived access key is a static secret that must be stored somewhere, an environment variable, a config file, a secrets manager, and rotated manually or via automation; if it leaks, it remains valid until someone notices and revokes it. An IAM role attached to an EC2 instance profile or a Lambda execution role is assumed automatically by the AWS SDK, yielding short-lived credentials that are rotated transparently and expire on their own even if never explicitly revoked. This removes the entire class of "leaked long-lived credential" risk for workloads that run on AWS compute, which is why roles are the default recommendation over access keys whenever the workload runs inside AWS.
A socket shows up in the LISTEN state versus ESTABLISHED. What is actually different about what that socket is doing?
LISTEN means a server-side socket is bound to a port and passively waiting to accept incoming connection requests, it isn't attached to any specific remote peer yet. ESTABLISHED means a full connection has completed its handshake and is actively associated with a specific remote address and port, data can flow in both directions. Seeing a service you expect to be running not show a LISTEN socket on its expected port is usually the very first, most direct signal that the service isn't actually up or isn't bound where you think it is.
Why does Linux split user information across /etc/passwd and /etc/shadow instead of keeping everything, including the password hash, in one file?
/etc/passwd has to be world-readable, ordinary tools and commands need to map UIDs to usernames and look up home directories or login shells for every user on the system. If password hashes lived there too, every local user could copy them out and run an offline cracking attempt. /etc/shadow holds the actual encrypted password (and related aging data) and is readable only by root, while /etc/passwd keeps a placeholder character (commonly `x`) in the password field, preserving the UID-lookup functionality everything else depends on without exposing anything crackable.
What does contextual retrieval actually change about the chunking process, and what measurable difference did it make?
Instead of embedding each chunk as extracted, contextual retrieval prepends a short, chunk-specific explanatory context before embedding it, turning "The company's revenue grew by 3%..." into something like "This chunk is from an SEC filing on ACME Corp's performance in Q2 2023; the company's revenue grew by 3%...", generated automatically per chunk rather than written by hand. In Anthropic's published results, this reduced retrieval failures by 49%, and combining it with reranking (a second relevance-scoring pass over retrieved candidates) reduced failures by 67%, a substantial, measured improvement from addressing the isolated-chunk context problem directly rather than only tuning the embedding model or retrieval algorithm.
What is the difference between durability and availability in S3, and why does it matter when picking a storage class?
Durability is the probability that a stored object is not lost over a year, and S3 Standard, Standard-IA, and every Glacier class are all designed for the same 99.999999999% (11 nines) durability. Availability is how often the object can actually be successfully retrieved on demand, and that number does vary by class, 99.99% for Standard down to 99.5% for One Zone-IA. It matters because a cheaper class is not automatically a less durable one, S3 One Zone-IA is exactly as durable as Standard-IA per object, but it is not resilient to the loss of its single Availability Zone at all, since it isn't replicated across multiple zones the way every multi-AZ class is.
Python Virtual Environments & Packaging
Why every Python project needs an isolated environment, what a lockfile actually pins down that a requirements list doesn't, and how to avoid the global-install dependency trap.
Why is scanning IaC source (Terraform files) not sufficient on its own, without also checking the plan?
Static scanning of Terraform source can catch some misconfigurations (a hardcoded insecure default) but can't see values that only exist after variables, data sources, and module composition are actually resolved, an insecure setting could depend on a variable supplied at runtime that static source scanning alone can't evaluate. The plan is the fully resolved, concrete set of resources Terraform is actually about to create or change, which is why policy-as-code tools evaluate the plan, not just the source, as the authoritative point to check against before anything is provisioned.
A custom dropdown built entirely from styled divs passes a visual design review. What is likely still broken for a keyboard-only or screen-reader user, and why doesn't looking right catch it?
Without the correct ARIA roles/states (or, better, a native `<select>`), a div-based dropdown typically has no way to be reached or operated via keyboard alone (no built-in Tab/Enter/Arrow-key handling), and a screen reader has no semantic information telling it "this is a dropdown, it is currently closed, here are its options," so it may announce nothing meaningful at all. A purely visual review can't catch this because the div looks and behaves correctly with a mouse, the missing behavior only surfaces via keyboard navigation or assistive technology, which is exactly why accessibility has to be tested directly with a keyboard and a screen reader, not inferred from how a component looks.
Build a Secure Azure Environment in Minutes with Bicep: VMs, Networking, Private Endpoints & Blob Replication
A hands-on Infrastructure-as-Code lab deploying a production-ready Azure environment from a single Bicep template.
Azure Policy, Tags, and Resource Locks Explained: A Complete Governance Guide for Cloud Engineers
Effective governance is essential as cloud environments grow. Without proper controls, organizations often face challenges in visibility, accountability, and cost tracking. In this lab, we explore how to implement governance practices in Azure using Azure Policy , Resource Tags , and Resource Locks…
At what point in the Terraform workflow are Sentinel (or similar policy-as-code) checks evaluated, and why does that timing matter?
Policy checks evaluate against the plan, the output of `terraform plan`, before `terraform apply` actually provisions anything, which means a policy violation blocks the run from proceeding to apply at all. Evaluating against the plan rather than the already-applied state is what makes this a preventive control instead of a detective one; the non-compliant resource is stopped before it exists, not flagged for cleanup afterward once it's already live and potentially already been exploited or has already incurred cost.
Why is using a mutable object (like a list) as a default argument value a common bug in Python?
Default argument values are evaluated exactly once, when the function is defined, not on every call, so a mutable default like `def f(items=[])` creates one list object that is shared across every call that doesn't explicitly pass its own `items`. Appending to it in one call leaves those items present the next time the function is called with the default, which looks like inexplicable state leaking between unrelated calls. The fix is defaulting to `None` and creating a new list inside the function body when `items is None`, so every call that needs the default gets its own fresh object.
What does "run to completion" mean for a single task or microtask, and why does it matter for reasoning about shared state?
Once a job (a task or a microtask) starts running, it executes entirely before any other job gets a chance to run, JavaScript cannot pause a running function partway through to let another callback interleave, the way a preemptively-scheduled thread in a language like C could be interrupted mid-function. This is what makes synchronous JavaScript code within a single function safe from data races on shared state without needing locks, whatever a function does to shared variables happens atomically from the perspective of any other queued job, even though the language is single-threaded and asynchronous.
Why would you add a second disk to an existing volume group instead of just creating a new, separate filesystem on it?
Adding a disk as a new physical volume to an existing volume group extends that VG's total capacity, which lets an existing logical volume (and the filesystem on it) be grown into the new space without unmounting it, moving data, or changing the mount point the rest of the system already depends on. Creating a second, separate filesystem on the new disk instead means the original filesystem is still capacity-constrained by its original disk, and anything needing more room has to be manually split or migrated across two independent mount points rather than one that simply grew.
If a microtask itself queues another microtask while it's running, does that new microtask wait for the next event loop iteration, or does it still run before the next macrotask?
It still runs before the next macrotask. The rule isn't "run the microtasks that were queued when this iteration started", it's "drain the microtask queue completely," and if executing a microtask adds another one, that new one is still part of the queue being drained. This means a chain of microtasks that keep scheduling more microtasks can, in principle, starve the event loop from ever reaching the next macrotask (a real, documented way to accidentally block timers and rendering), which is different from a single flat batch of microtasks all queued up front.
Building a Production-Ready AKS GitOps Platform with Terraform and ArgoCD
The DevOps Project That Finally Made Kubernetes, GitOps, and Terraform Click