Content deleted Content added
Portnadler (talk | contribs) Add sections on OpenVMS implementation |
Portnadler (talk | contribs) Tidy up |
||
Line 13:
===Resources===
The DLM uses a generalised concept of a '''resource''', which is some entity to which shared access must be controlled. This may relate to a file, a record, or an area of shared memory, but can be anything 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
Line 26:
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 of access to the resource. Once a lock has been 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 Lock (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 higher levels of lock can be obtained on subordinate resources.
*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 higher levels of lock can be obtained on subordinate resources.
*Protected Read (PR). This is the traditional ''share lock'', which indicates a desire to read the resource but prevents other from updating it. Others can however also read the resource.
*Protected
*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 42:
{| class="wikitable"
|-
| '''Mode''' || '''NL''' || '''CR''' || '''CW''' || '''PR''' || '''
|-
| '''NL''' || Yes || Yes || Yes || Yes || Yes || Yes
Line 52:
| '''PR''' || Yes || Yes || No || Yes || No || No
|-
| '''
|-
| '''EX''' || Yes || No || No || No || No || No
Line 59:
===Obtaining a lock===
A process can obtain a lock on a resource by ''enqueueing'' a lock request. This is
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).
Line 83:
==References==
[http://h71000.www7.hp.com/doc/82FINAL/4527/
| |||