Distributed lock manager

Coordinate named lock ownership and compatible access modes across cluster nodes so shared resources retain mutual-exclusion and recovery guarantees despite concurrency and membership change.

Version

v2 · 2026-09-19 · History

Domain-specific #

1697

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomain

Distributed Resource Locking → Computer Science & Software Engineering

Aliases

DLM, Cluster lock manager, Distributed lock service

Core Idea

A distributed lock manager is a cluster service that gives processes on different nodes a shared lock namespace and arbitrates access to named resources. Clients request a mode such as shared or exclusive, the manager applies a compatibility relation to current holders and queued requests, and a grant represents permission under the service's membership and recovery assumptions. The identity includes distributed ownership state, conversion and queueing, and failure recovery; it is not simply a mutex library called over a network.

How would you explain it like I'm…

The Bike-Turn Keeper

Imagine kids in many different houses who all want to use the same special bike. They have to ask one helper, who keeps track of who has the bike and who is waiting in line. Several kids can look at the bike at once, but only one can ride it. If a kid goes home without giving it back, the helper has to notice and make sure that kid cannot ride it anymore before letting the next kid have a turn.

Taking Turns Across Computers

When many computers work together, they sometimes need to share the same thing, like a file, without messing each other up. A distributed lock manager is a service that hands out permission slips, called locks, for named things. A computer can ask for a shared lock, so others can read too, or an exclusive lock, so only it can use the thing. The manager keeps track of who holds what and who is waiting in line. Because a computer can crash while holding a lock, the manager also has to notice crashes, take locks back, and make sure a crashed-then-returning computer does not act as if it still has permission.

Cluster-Wide Lock Arbiter

A distributed lock manager (DLM) is a service in a computer cluster that lets processes on different machines share one set of named locks and decides who can access each resource. A process asks for a lock in a mode, like shared (many readers) or exclusive (one writer). The manager checks that request against who already holds the lock and who's waiting, then grants it, queues it, or lets a holder upgrade or downgrade its lock. What makes it more than a normal lock called over a network is failure handling: a crashed machine can't release its locks, so the DLM has to detect failures, recover lock state, and make sure an out-of-date client can't keep acting as if it still holds a lock. A DLM also doesn't magically make changes safe: the program has to actually respect the lock and handle saving its data separately.

 

A distributed lock manager is a cluster service providing processes on different nodes with a shared lock namespace and arbitration over named resources. Clients request modes such as shared or exclusive; the manager applies a compatibility relation against current holders and queued requests, serializing incompatible grants, and supports queueing and conversion (upgrading or downgrading an existing grant). Hierarchical resources may carry parent-child constraints. Architecturally, some DLMs assign a master node per resource, while others distribute or replicate management state, but all preserve the same arbitration contract. Because a failed node cannot release its locks, membership detection, fencing or equivalent exclusion, and lock-state recovery are load-bearing, and a stale client whose grant is no longer authoritative must be prevented from acting, often via generation numbers or fencing tokens. A DLM is distinct from a local mutex library called over the network, from consensus (though consensus may underpin it), and from time-bounded leases (not all locks are leases). It does not make application updates atomic by itself: protected operations must honor the lock and coordinate durable data separately, and network partitions force trade-offs between safety and availability.

Scope of Application

The abstraction is literal wherever practitioners can identify the same constitutive roles, apply the same boundary tests, and obtain the same kind of output. The following habitats are uses of Distributed lock manager itself, not metaphors based only on resemblance.

• Cluster file systems. Coordinating metadata and data structures shared by multiple hosts.
• Shared volume management. Serializing updates to cluster-visible storage configuration.
• High-availability services. Protecting singleton or mode-limited ownership during failover.
• Distributed databases. Coordinating named records or metadata when a lock-service architecture is chosen.
• Recovery analysis. Determining which grants survive, wait, or are rebuilt after membership change.
• Deadlock management. Detecting or resolving cycles among distributed wait dependencies.

Clarity

A clear account of Distributed lock manager must preserve the recognition invariant stated in the Core Idea rather than rely on the title alone. State the namespace, lock modes, compatibility matrix, and ownership granularity. Specify which component decides grants and how its authority changes with membership. Describe the stale-holder barrier without claiming that failure detection is perfectly instantaneous. Separate lock safety from durability, transaction atomicity, and application-level invariants.

Manages Complexity

Distributed lock manager manages complexity by replacing a diffuse field of observations or possible operations with a bounded role structure: global namespace supplies nodes identify the same shared resource by a stable lock name.; requesting client supplies a process asks for acquisition, conversion, release, or notification.; lock mode supplies shared, exclusive, or richer modes encode the requested access strength.; compatibility matrix supplies a declared relation determines which modes may coexist.; ownership record supplies distributed state identifies current holders, conversions, and waiters..

Abstract Reasoning

1. Name the resource and map every client to the same lock identity.
2. Select the weakest access mode that protects the intended operation.
3. Compare the request with granted and converting modes under the compatibility relation.
4. Grant immediately or place the request in an explicitly ordered wait structure.
5. Track ownership changes and notifications across participating nodes.
6. On membership loss, establish exclusion before redistributing or rebuilding grants.

Knowledge Transfer

The strict upward abstraction is Mutual Exclusion. A distributed lock manager instantiates Mutual Exclusion because its core safety obligation prevents incompatible parties from simultaneously holding authority over the same named resource. Within distributed resource locking, the full mechanism transfers literally when the same roles and boundary tests recur. Beyond that domain, only the parent-level skeleton should travel. Reusing the label Distributed lock manager after removing its constitutive vocabulary would hide a change of mechanism behind an analogy. The honest transfer rule is therefore two-stage: recognize the domain-specific pattern first, then lift only the parent relation that remains invariant under a substrate change.

Relationships to Other Abstractions

Current abstraction Distributed lock manager Domain-specific

Parents (1) — outgoing typed relations

• Distributed lock manager is a kind of Mutual Exclusion Prime

  A distributed lock manager instantiates Mutual Exclusion because its core safety obligation prevents incompatible parties from simultaneously holding authority over the same named resource.

Hierarchy paths (5) — routes to 4 parentless roots

• Distributed lock manager → is a kind of Mutual Exclusion → is a kind of, typical Coordination → presupposes Concurrency

Show alternative paths (4)

Neighborhood in Abstraction Space

Distributed lock manager sits in a sparse region of the domain-specific corpus (94^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

• Distributed Data Store — 0.79
• Zooko's Triangle — 0.78
• DLL Hell — 0.77
• Locks with ordered sharing — 0.77
• Mixed Criticality — 0.77

Computed from structural-signature embeddings · 2026-10-25