conversion . Conversion requests can be pro
cessed more efficiently than new lock requests
because all the data structures are already i n
place, and the resource manager has already been
identified. If a conversion request is made on the
node managing the resource, no messages need
be exchanged. If the resource manager is not the
node on which the request is being made, either
one or two messages are required . For example,
i n some cases in which the requested mode is
compatible with the granted mode, the request
3 5
VAXcluster Systems
The V AXjVMS Distributed Lock Manager
NODE A
RESOURCE MANAGER
NODE 8
DIR ECTORY NODE
CD
CD
0
0
NODE C
When a new root-lock request is received, local copies of the resource block and lock block are created.
A message requesting a lock is then sent to the directory node.
The response i ndicates that node A is currently the resou rce manager.
The lock request i s again sent to node A . A master-copy lock block i s created o n the resou rce manager and linked to the resource block.
KEY:
(D
A granted response is returned.
Dl
R ESOU RCE BLOCKD
(IMPLEMENTED AS A RESOU RCE BLOCK} DIRECTORY ENTRY FOR RESOU RCE 0 LOCK BLOCKFigure 3 New Root-lock Request When a Resource Manager Exists
can be unilaterally granted , and a single message sent ro noti fy the resource manager of the change . In others, the resource manager must make a dec ision based on the other requests t ha t are granted . A request i s then sent to the resource manager, who must respond . Jn all cases, no com munications are req uired with the di rectory node. Figure 6 il lustrates a conversion request .
Operation During Periods of Resource Contention
The operation is slightly more complicated dur ing periods of contention . When a resource man ager receives a lock request t hat cannot be granted because an incompatible lock exists, two
actions are required . First, all holders of incom patible locks that have indicated a desire ro receive blocking ASTs must be noti fied that a pro cess is waiting. To accomplish this, a message is sent to each node where a lock holder resides. The process holding the lock is notified only once , even though it may be blocking multiple lock requests. Second , the requester of the lock must be told to wait; this is accomplished by sending a response to the lock request. When the blocking lock is later released, a message is sent to each waiting requestor indicating that the lock is now granted . Table 4 su mmari zes the numbers of messages used for different types of lock requests .
Digital Tecb�Jical journal
NODE A
RESOURCE MANAGER
NODE B
DIR ECTORY NODE
D
CD
0
NODE C
When a sublock request is received. a lock block is created. If this is the first lock on the sub· resource, a resource block is also created. The request is sent to the resou rce manager. No d irectory lookup is requ ired.
If locks already exist on the subresource . only a lock block is created. Otherwise, both a lock block and a resource block are created.
(D
A granted response is returned. KEY:D
0RESOURCE BLOCK
DIRECTORY ENTRY FOR RESOURCE (IMPLEMENTED AS A RESOURCE BLOCK) LOCK BLOCK
Figure 4 A Subtock Request on a Node that Is Not the Resource Manager Scaling Behavior of the Distributed
Lock Manager
It can be shown that the number of messages requ ired for any locking operation is bounded by a small constant that is independent of the num· ber of nodes, or cl uster size, i n a VAXcluster sys· re m . This section addresses how the size of the dara representing the locking state and the total number of locking messages vary with a cluster's size .
The distributed lock manager uses a fixed-size control block to represent both a lock and a lock request . An instance of this control block exists on the node requesting the lock. If the resource manager is a different node, another instance exists on the resource manager. A resource is rep·
Digital Technical journal No. 5 September I Y87
resented by another fixed-size control block. An
instance of this control block exists on each node requesti ng the lock, on the resource manager, and on the directory node . Whenever any of these categories overlap ( i . e . , requestor, resource man· ager, and directory node) , only one instance of the control block is present. The control blocks for Jocks and resources are dynamicaLly allocated and deal located.
At l east one lock is represented for every resource represented. Conversely, a resource is represented for every lock represented . For each lock, the u pper bound on the storage require· ments is two lock control blocks and three resource control blocks . This upper bound is usually quite loose and depends on a c luster's size.
37
VAXcluster Systems
The VAX/VMS Distributed Lock Manager
NODE A
RESOURCE MANAGER
NODE B
DIR ECTORY NODE
0
CD
When an unlock request is received for a root lock, the lock block is deallocated. If this is the last lock on the resource. the resou rce block is also deallocated.
A message is sent to the resource manager. No response is required.
The resource manager deallocates the lock block. If this i s the last lock on the resource. the resource block i s also deallocated.
0
A message is sent to the directory node.(I)
The directory entry is removed. KEY:D
DRESOURCE BLOCK
D I RECTORY ENTRY FOR RESOURCE