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: v1 · 2026-08-30 · History
Domain-specific #: 1697
Origin domain: computer science
Subdomain: distributed resource locking
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.^[1]^[1]

The manager maps resource names to lock records, tracks owners and modes, serializes incompatible grants, and communicates state among participating nodes. Hierarchical resources can carry parent-child constraints, and conversions can upgrade or downgrade an existing grant. Because a failed node cannot politely release locks, membership detection, fencing or equivalent exclusion, and lock-state recovery are load-bearing. Some designs assign masters to resources; others distribute or replicate management state. These architectural variants preserve the same arbitration contract.^[2]^[2]

A DLM does not make arbitrary application updates atomic: the protected operation must actually honor the lock and coordinate durable data separately. It is not identical to consensus, although consensus or membership services may support its decisions; not every lock is a time-bounded lease; and local process locks lack cross-node failure semantics. Network partitions expose safety-versus-availability choices, and a stale client must be prevented from acting after its grant is no longer authoritative, often through fencing or generation information.^[3]^[3]

Structural Signature¶

Global namespace. Nodes identify the same shared resource by a stable lock name.
Requesting client. A process asks for acquisition, conversion, release, or notification.
Lock mode. Shared, exclusive, or richer modes encode the requested access strength.
Compatibility matrix. A declared relation determines which modes may coexist.
Ownership record. Distributed state identifies current holders, conversions, and waiters.
Arbitration rule. The service orders or selects compatible grants without violating safety.
Membership and failure detector. Cluster state identifies nodes whose grants may need recovery.
Recovery barrier. Fencing or an equivalent mechanism prevents failed or stale holders from corrupting the resource.

What It Is Not¶

Not a local mutex. A process-local primitive has no cluster membership or remote-owner recovery.
Not distributed consensus. Consensus chooses a value or log order; a DLM exposes a resource-lock contract.
Not a database transaction manager. Transactions add atomicity and durability beyond lock ownership.
Not a lease by definition. Some locks have time bounds, but expiry is not universal to the abstraction.
Not fencing alone. Fencing excludes a failed node but does not maintain names, modes, and queues.
Not a guarantee of application correctness. Clients can misuse locks or update an unprotected resource.

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. These declarations are not editorial extras: each changes what observations count, which transformations are licensed, and what conclusion can be drawn. A reader should be able to reconstruct the input, the operative rule, the output, and at least one defeater from the account without consulting an implementation or guessing an unstated convention.

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.. The compression is useful because it localizes disagreement. One can ask whether the input was properly formed, whether a constitutive relation held, whether an alternative explanation defeats the inference, or whether the output was overinterpreted. The same compression can mislead when its discarded detail is exactly what the decision requires. A reference-grade use therefore reports both the invariant retained and the information intentionally lost.

Abstract Reasoning¶

Name the resource and map every client to the same lock identity.
Select the weakest access mode that protects the intended operation.
Compare the request with granted and converting modes under the compatibility relation.
Grant immediately or place the request in an explicitly ordered wait structure.
Track ownership changes and notifications across participating nodes.
On membership loss, establish exclusion before redistributing or rebuilding grants.
Audit deadlock, starvation, stale-client, and application-bypass failure paths separately.
Test the candidate interpretation against the nearest named confusable rather than accepting a shared surface feature.
State the conclusion at the same scope as the source conditions, and retain uncertainty or nonuniqueness where the construct does not remove it.

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.

Examples¶

Canonical¶

Three cluster nodes mount a shared file system. Two readers obtain compatible shared locks on one metadata object; a third node's exclusive conversion waits. One reader fails. The service does not simply assume its grant vanished: cluster recovery first excludes the failed node from shared storage, reconstructs ownership, and only then can the incompatible exclusive request be granted safely.

Mapped back: input and conventions → constitutive role test → bounded output → explicit interpretation and defeater check.

Applied / In Practice¶

A web service uses a distributed lock around a job but writes to an external system that accepts requests from stale clients. During a partition, an old holder continues acting after a new holder is elected. The DLM's mutual-exclusion intent is not enough because the resource lacks a fencing token or comparable stale-writer check. This is an integration failure, not evidence that two simultaneous grants were legitimate.

Mapped back: field observation or problem → candidate recognition → confusable and limit checks → appropriately scoped conclusion.

Structural Tensions¶

T1: Safety versus availability. A partition can prevent proving that an old holder is excluded. Diagnostic: Does the system delay grants or risk simultaneous authority?
T2: Failure suspicion versus actual failure. Timeouts are evidence, not proof, of node death. Diagnostic: What establishes the recovery barrier before reassignment?
T3: Central authority versus distribution. A master simplifies arbitration while distributing state improves locality or resilience. Diagnostic: Where is the authoritative record for this resource now?
T4: Rich modes versus analyzability. Mode lattices reduce unnecessary exclusion but complicate conversion and deadlock. Diagnostic: Is the compatibility matrix complete and tested for conversions?
T5: Fairness versus throughput. Queue order can prevent starvation while limiting compatible batching. Diagnostic: Which scheduling guarantee is actually part of the service contract?
T6: Autonomous manager versus Mutual Exclusion. Mutual exclusion states the invariant; a DLM adds namespace, modes, membership, recovery, and distributed authority. Diagnostic: Would the account still distinguish a DLM after removing node failure and ownership recovery?

Structural–Framed Character¶

A distributed lock manager is structural and operationally socio-technical: the compatibility invariant is formal, while timeout, membership, and recovery policies are engineered commitments. The five framing criteria point in a consistent direction. Evaluative weight is limited to whether the defining conditions are met, not whether the outcome is desirable. Human practice matters to the extent that experts choose conventions, instruments, or reporting thresholds, but those choices do not make every verdict arbitrary. Institutional history explains the name and standard use; it does not replace the recognition rule. The operative vocabulary travels within the home field and closely adjacent subfields, while transfer farther away requires translation to the parent prime. Thus recognition remains disciplined even where interpretation is defeasible.

Structural Core vs. Domain Accent¶

What is skeletal. A distributed lock manager instantiates Mutual Exclusion because its core safety obligation prevents incompatible parties from simultaneously holding authority over the same named resource. This is the part that can be expressed without the candidate's specialist nouns.

What is domain-bound. The domain accent is a cluster-wide namespace, mode compatibility, remote ownership, request conversion, membership change, fencing, recovery, and distributed wait dependencies. Remove those elements and the result is no longer Distributed lock manager; it is only the parent relation or a loose analogy.

Why this does not clear the prime bar. The name does not recur with unchanged diagnostics across three independent domains. What transfers is already represented by prime:mutual_exclusion. The candidate remains autonomous because its in-domain recognition rule, failure modes, and consequences are stable, but its vocabulary and interventions do not float free of the home substrate.

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

The prospective workspace queue contains one strict upward edge to prime:mutual_exclusion. No live DAG mutation is authorized.

Relationships to Other Abstractions¶

Current abstraction Distributed lock manager Domain-specific

Parents (1) — more general patterns this builds on

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.

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 — Software Dependency & Coordination Failures (5 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Local lock manager. Arbitrates within one kernel or database process without cluster-failure recovery.
Lease service. Uses time-bounded grants and clock assumptions that a DLM need not require.
Consensus service. Orders proposals or maintains a replicated log rather than exposing lock modes directly.
Fencing. Excludes stale actors but does not allocate compatible lock ownership.
Transaction manager. Coordinates atomic commit, rollback, and durability in addition to any locks.
Semaphore. Counts permits and usually lacks a distributed membership-recovery contract.

References¶

[1] Red Hat. (2025). Red Hat Enterprise Linux 8: Configuring GFS2 File Systems, sections on the Distributed Lock Manager and glocks. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_gfs2_file_systems/ registry ↩a ↩b

[2] Gray, Jim, and Andreas Reuter. (1992). Transaction Processing: Concepts and Techniques. Morgan Kaufmann. ISBN 978-1-55860-190-1. registry ↩a ↩b

[3] Burrows, Mike. (2006). ‘The Chubby Lock Service for Loosely-Coupled Distributed Systems.’ OSDI '06. USENIX. https://www.usenix.org/legacy/event/osdi06/tech/full_papers/burrows/burrows.pdf registry ↩a ↩b