Tensions in Practice: Simple exclusion in tension with independent progress¶
Concurrent updates · independent records
Two workers can update different records without touching the same state. A single shared lock is simple to manage, but makes either worker wait while the other holds it. Separate record locks allow independent updates to overlap, at the cost of more lock-management rules. The important question is which state must change together: a narrow lock is useful only if it still protects the entire correctness requirement.
Keep updates correct
Prevent overlapping updates from observing or changing protected state halfway through an operation.
Let independent work progress
Avoid making an update wait for another operation that cannot affect its result.
Why these aims pull against each other
A broad lock uses one exclusion boundary for many operations, so it serializes even independent work. Splitting that boundary removes some contention but adds coordination responsibilities, especially when an operation needs several records.
Choose an arrangement to see what changes and what remains difficult.
Qualitative paths and conditions, not measured costs, timings or performance guarantees.
What this choice protects
What it costs
When it fits
Compare the arrangements
Use one shared lock
Both illustrated updates acquire the same lock before modifying either record.
- What it protects
- There is one exclusion boundary to reason about, and operations inside it cannot overlap with another holder.
- What it costs
- An update to A can delay an independent update to B; a long-held lock becomes a bottleneck.
- When it fits
- A defensible choice when the state is tightly coupled, operations must be atomic together, or the coordination simplicity is worth the contention. All accesses still have to obey the lock.
Illustration note: The two records are an editorial example. The common lock shows serialization, not a guarantee of fairness or recovery after a failed holder.
Use record locks
Updates confined to A acquire A’s lock; updates confined to B acquire B’s lock.
- What it protects
- The independent updates can proceed without contending for one common lock.
- What it costs
- More lock boundaries mean more management overhead. Multi-record operations may need several locks and can deadlock if their acquisition order is inconsistent.
- When it fits
- Useful when the records are genuinely independent for the illustrated operations; cross-record invariants need an additional, consistent coordination rule.
Illustration note: The diagram intentionally shows only single-record operations. It does not suggest that a transfer or other joint update can safely take one lock and ignore the other.
What this illustration does—and does not—establish
Concurrency: Independence vs Coordination supplies the granularity tradeoff. The mutex mechanism supports narrowly scoped critical sections and warns about over-serialization and multi-lock cycles. The record example is editorial.
- Concurrency can be interleaved on one processor; this diagram does not promise physical parallelism.
- Fine lock granularity does not remove synchronization or automatically preserve a cross-record invariant.
- Neither diagram establishes fairness, failure recovery or freedom from every deadlock.
Source entries
Concurrency
Concurrency: Independence vs Coordination supplies the conflict examined here.
Independence vs Coordination
- T1: Independence vs Coordination. More independent concurrency enables better parallelism and fault isolation, but requires more explicit synchronization to ensure correctness. Over-synchronizing (pessimistic locking, global locks) serializes the system; under-synchronizing (optimistic concurrency) risks race conditions and invariant violations. A common failure is choosing the wrong synchronization granularity: locks too coarse (unnecessary blocking) or too fine (excessive synchronization overhead) .
Core Idea
Concurrency is the ability of a system to manage *multiple independent or interdependent processes occurring simultaneously*, often requiring explicit coordination, synchronization, or conflict resolution. The essential commitment is that separate loci of execution or activity proceed in time-overlapping fashion, raising questions of *ordering, resource contention, and logical correctness* under concurrent interleaving.
Mutex or Lock
Explains exclusive acquisition and the costs of overly broad locks and inconsistent multi-lock order.
How it works
- Mark the critical section. Identify the exact span of work where simultaneous access corrupts the outcome — the read-modify-write of a shared value, the moment a machine is energized — and wrap *only* that span. Everything outside stays parallel. - Acquire before entering. An actor takes the lock; if another holds it, the actor blocks (or, with a try-lock, gives up and does something else).
When it helps, and when it misleads
The failure mode is that a lock held too broadly or too long becomes the system's bottleneck — over-serialization, in which work that could have run in parallel queues up behind one occupant. Two locks acquired in inconsistent orders can also wait on each other forever, and a low-priority holder can stall a high-priority waiter — priority inversion, the fault that famously reset the Mars Pathfinder lander until its lock protocol was patched.