Locking prevents conflicts but blocks parallelism
Aliases: parallelism cost of pessimistic locking · serialized collaboration · lock queueing
What it is
Handling concurrency with locks buys certainty of no conflict and pays with parallelism itself: while a region is locked, everyone else can only wait or work around it. This is not merely a technical queue — it rewrites collaborative behavior. People defer ideas because "that part is locked," spawn side copies, or simply disengage. Locking turns "working together" into "taking turns"; conflicts disappear at the price of collaboration density. The test of a locking scheme is not how many conflicts it eliminated, but whether the serialization it introduces is cheaper than the conflicts it prevented.
Why it happens
A lock's exclusivity is binary: holding it means everything, not holding it means nothing. That mismatches the real rhythm of joint work — two people editing the same region rarely collide everywhere; most intents could coexist — but a lock cannot express "mostly parallel, mutually exclusive in a small spot"; it hands the whole region to one person at a time. The behavioral fallout runs along three paths. Waiting: the newcomer is barred, attention and train of thought broken; the longer the wait, the stronger the pull to leave. Workarounds: blocked users create private copies and merge later — producing exactly the divergence the lock was meant to prevent. Withdrawal: repeatedly blocked people invest less in the shared space and retreat to solo work. All three paths push actual parallelism below the headcount the system nominally supports. The underlying structure of the trade-off: conflict cost is probabilistic and episodic; serialization cost is deterministic and continuous.
Studying it
- Paradigm: system logs comparing locked versus merged systems on the same tasks — per-person wait time, share of concurrent operations, leakage into side copies; controlled experiments manipulating the concurrency mechanism (lock / automatic merge / no control), measuring group task completion time, simultaneous-editing share, and the distribution of contribution across members.
- Variables: concurrency mechanism and lock scope as independents; wait time, achieved parallelism, workaround behavior, and contribution balance as dependents.
- Use in interface research: supplying the data for "does this collaborative context deserve locks" — when conflict losses are smaller than serialization losses, the lock is a liability.
- Methodological caveat: the cost of waiting is not only duration but broken trains of thought and eroded willingness to participate, which logs cannot see; pair telemetry with interviews or before/after engagement measures. Lab tasks come pre-loaded with motivation and mask the real-world churn of "blocked twice, then gone."
Where it stops holding
Locks are not uniformly bad. Where the region is naturally exclusive (I am rewriting this section; nobody else should touch it) and the cost of a bad merge is extreme (the core formula of a financial model, a legal clause), serialization is reasonable insurance. Lock damage also scales with hold duration: a seconds-long row lock is imperceptible; an hours-long whole-document lock is a disaster. Rule of thumb: in low-conflict, long-hold contexts the expected cost of locking almost always exceeds its benefit — switch to a detect-and-notify optimistic scheme.
Applying it
- Before introducing locks, estimate two quantities: the region's real conflict rate (usually far below intuition) and the average lock hold time; low conflict plus long holds means drop the lock.
- When locks are necessary, shrink them to the smallest exclusive unit and let waiters "book the next slot" instead of polling.
- Show who holds the lock and the expected remaining time, turning unpredictable waiting into predictable queueing.
- Offer a formal workaround route (propose changes via a copy) so users don't create uncontrolled divergence through informal copies.
- Verification: track per-person lock waits (count and duration) and the trend in out-of-lock copies; any metric climbing steadily means serialization has outpriced conflict.