Distributed lock manager: Difference between revisions

Content deleted Content added
JK
Tag: Reverted
m Reverted edits by 5.43.212.9 (talk) (HG) (3.4.10)
Line 1:
{{refimprove|date=October 2010}}
 
[[Operating system]]s use lock managers to organise and serialise the access to resources. A '''dstdistributed clusteringlock systemmanager''' to(DLM) comeruns intoin every machine in widespreada usecluster, relieswith onan theidentical copy of a cluster-wide lock database. In this way a DLM provides [[OpenVMSsoftware application]]s DLMwhich inare just[[distributed thisprogramming|distributed]] wayacross a cluster on multiple machines with a means to synchronize their accesses to [[shared resource]]s.
 
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, relies on the [[OpenVMS]] DLM in just this way.
 
==VMS implementation==
Line 15 ⟶ 17:
* Field
 
A [[process (computing)|process]] can then acquire locks on the database as a whole, and then on particular parts oof 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.
* Null (NL). Indicates interest in the resource, but does not prevent other processes from locking it. It has the advantage that the resource and its [[#Lock value block|lock value block]] are preserved, even when no processes are locking it.
* Concurrent Read (CR). Indicates a desire to read (but not update) the resource. It allows other processes to read or update the resource, but prevents others from having exclusive access to it. This is usually employed on high-level resources, in order that more restrictive locks can be obtained on subordinate resources.
Line 26 ⟶ 32:
 
{| class="wikitable"
|-
|- {{Yes}} || {{No}}
! Mode || NL || CR || CW || PR || PW || EX
|-
! NL
| {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
! CR
| {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{No}}
|-
! CW