A distributed lock coordinates access to a shared resource across multiple machines, so that at any moment only one process holds the lock and is allowed to act. It is the network-wide cousin of the mutex a single program uses to guard memory, and it is most often used to elect a leader or to make sure only one worker touches a given piece of work at a time.
Doing this safely is harder than it looks. A lock holder can pause (for example during a long garbage-collection stall), its lease can quietly expire, and meanwhile another process can be granted the same lock, leaving two processes that both believe they hold it. Google’s Chubby paper, which describes one of the earliest production lock services, treats locks as advisory and relies on a consensus-backed cell to keep the lock state consistent and fault-tolerant.
A standard defense is the fencing token. Martin Kleppmann’s write-up on distributed locking explains that the lock service hands out a monotonically increasing number each time the lock is granted; every write to the protected resource must carry that token, and the resource rejects any write bearing an older token. This protects correctness even when a stalled process wakes up holding a lock it has actually lost.
Distributed locks are provided by coordination services such as Chubby, ZooKeeper (whose recipes document fully distributed locks), and etcd. Kleppmann’s article also examines Redis-based locking and the Redlock algorithm, arguing it is unsafe for correctness-critical use because it lacks fencing tokens and depends on timing assumptions that real systems violate.