Distributed lock manager: Difference between revisions

Revision as of 04:33, 6 July 2021

Revision as of 03:16, 20 July 2021

Line 5:

DLMs have been used as the foundation for several successful [[clustered file system]]s, in which the machines in a [[computer cluster|cluster]] can use each other's storage via a unified [[file system]], with significant advantages for performance and [[high-availability|availability]]. The main performance benefit comes from solving the problem of [[cache coherency|disk cache coherency]] between participating computers. The DLM is used not only for [[file locking]] but also for coordination of all [[disk (storage device)|disk]] access. [[VMScluster]], the first clustering system to come into widespread use, relied on the [[OpenVMS]] DLM in just this way.

=== Resources= ==

The DLM uses a generalized concept of a '''resource''', which is some entity to which shared access must be controlled. This can relate to a file, a record, an area of shared memory, or anything else that the [[application software|application]] designer chooses. A hierarchy of resources may be defined, so that a number of levels of locking can be implemented. For instance, a hypothetical [[database]] might define a resource hierarchy as follows:

Line 15:

A [[process (computing)|process]] can then acquire locks on the database as a whole, and then on particular parts of the database. A lock must be obtained on a parent resource before a subordinate resource can be locked.

=== Lock modes= ==

A process running within a VMSCluster may obtain a lock on a resource. There are six lock modes that can be granted, and these determine the level of exclusivity being granted, it is possible to convert the lock to a higher or lower level of lock mode. When all processes have unlocked a resource, the system's information about the resource is destroyed.

Line 50:

|}

=== Obtaining a lock= ==

A process can obtain a lock on a resource by ''enqueueing'' a lock request. This is similar to the [[QIO]] technique that is used to perform I/O. The enqueue lock request can either complete synchronously, in which case the process waits until the lock is granted, or asynchronously, in which case an [[Asynchronous System Trap|AST]] occurs when the lock has been obtained.

Line 56:

It is also possible to establish a ''blocking AST'', which is triggered when a process has obtained a lock that is preventing access to the resource by another process. The original process can then optionally take action to allow the other access (e.g. by demoting or releasing the lock).

=== Lock value block= ==

A lock value block is associated with each resource. This can be read by any process that has obtained a lock on the resource (other than a null lock) and can be updated by a process that has obtained a protected update or exclusive lock on it.

Line 62:

It can be used to hold any information about the resource that the application designer chooses. A typical use is to hold a ''version number'' of the resource. Each time the associated entity (e.g. a database record) is updated, the holder of the lock increments the lock value block. When another process wishes to read the resource, it obtains the appropriate lock and compares the current lock value with the value it had last time the process locked the resource. If the value is the same, the process knows that the associated entity has not been updated since last time it read it, and therefore it is unnecessary to read it again. Hence, this technique can be used to implement various types of [[cache (computing)|cache]] in a database or similar application.

=== Deadlock detection= ==

When one or more processes have obtained locks on resources, it is possible to produce a situation where each is preventing another from obtaining a lock, and none of them can proceed. This is known as a [[deadlock]] ([[E. W. Dijkstra]] originally called it a [[deadly embrace]]).<ref>{{cite book|page=105|url=https://books.google.com/books?id=E6wOK8OYBG4C&pg=PA105|title=Ada: Concurrent Programming|isbn=9780929306087|author1=Gehani|first1=Narain|year=1991}}</ref>