Daeseon Yoo

Wiki

Distributed lock

Mutual exclusion across processes and servers, not threads in one JVM. The principle under ShedLock, Redlock, and SELECT FOR UPDATE.

·principle · distributed-systems · concurrency · locking

Instances

The principle

A normal lock (synchronized, a mutex) coordinates threads inside one process. Run two instances and that lock is useless across them — each has its own. A distributed lock moves the exclusion to something all instances share, so only one of N actors is in the critical section at a time.

The deep point: it's the same mutual-exclusion idea, just with the shared state moved out of process memory and onto the network — which adds a failure mode in-process locks don't have (the holder can die while still "holding").

How it maps to practice

How it gets buried

"Distributed coordination at scale," "leader election as a service." Often the actual need is "don't run this twice," and a database unique constraint or an idempotent design is cheaper and safer than a lock.

Say it clearly

"Only one of the running instances does this at a time." And the trap: a lock isn't correctness — if the holder stalls past the lock's expiry, a second holder acquires it while the first still thinks it owns it. You need fencing tokens or a transaction-scoped lock.

In Korean

"분산 락" — left as the loanword "락", not the native "잠금" (which reads as a UI/screen lock). Devs say "락 잡는다" (grab the lock). The loanword survives specifically for the concurrency sense.