Distributed lock manager: Difference between revisions

Revision as of 12:42, 5 October 2016

Revision as of 15:50, 29 October 2016

Line 1:

{{refimprove|datte=October 2010|date=October 2010}}

Operating Systems use lock managers to organise and serialise the access to resources. A '''distributed lock manager''' (DLM) runs in every machine in a cluster, with an identical copy of a cluster-wide lock database. In this way a DLM provides [[software application]]s which are [[distributed programming|distributed]] across a cluster on multiple machines with a means to synchronize their accesses to [[shared resource]]s.

Line 11:

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:

* Database

* Table

* Record

* Field

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.

Line 21:

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 WriteRead (CWCR). Indicates a desire to read and(but not update) the resource. It also allows other processes to read or update the resource, but prevents others from having exclusive access to it. This is also usually employed on high-level resources, in order that more restrictive locks can be obtained on subordinate resources.

*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 ReadWrite (CRCW). Indicates a desire to read (but notand update) the resource. It also allows other processes to read or update the resource, but prevents others from having exclusive access to it. This is also usually employed on high-level resources, in order that more restrictive locks can be obtained on subordinate resources.

*Exclusive Protected Read (EXPR). This is the traditional ''exclusiveshare lock'', which allowsindicates reada and update accessdesire to read the resource, andbut prevents othersother from havingupdating anyit. accessOthers tocan ithowever also read the resource.

*Concurrent Write (CW). Indicates a desire to read and update the resource. It also allows other processes to read or update the resource, but prevents others from having exclusive access to it. This is also usually employed on high-level resources, in order that more restrictive locks can be obtained on subordinate resources.

* Protected ReadWrite (PRPW). This is the traditional ''shareupdate lock'', which indicates a desire to read and update the resource butand prevents otherothers from updating it. Others with Concurrent Read access can however also read the resource.

*Protected WriteExclusive (PWEX). This is the traditional ''updateexclusive lock'', which indicates a desire toallows read and update access to the resource, and prevents others from updatinghaving it. Others with Concurrent Readany access canto however read the resourceit.

*Exclusive (EX). This is the traditional ''exclusive lock'' which allows read and update access to the resource, and prevents others from having any access to it.

The following [[truth table]] shows the compatibility of each lock mode with the others:

Line 109 ⟶ 108:

{{Reflist}}

{{Refbegin}}

* [http://h71000.www7.hp.com/doc/82FINAL/4527/4527pro_044.html#jun_227 HP OpenVMS Systems Services Reference Manual –– $ENQ]

* [https://github.com/chadrem/officer Officer - A simple distributed lock manager written in Ruby]

* [http://sourceforge.net/projects/flom/ FLoM - A free open source distributed lock manager that can be used to synchronize shell commands, scripts and custom developed C, C++, Java, PHP and Python software]

{{Refend}}