Heading:

Alpine lock manager design, version 0

Page Numbers: Yes X: 527 Y: 10.5"

CSL Notebook Entry

To:Alpine designersDate:February 25, 1981

From:Mark BrownLocation:PARC/CSL

Subject:Alpine lock manager design, version 0File:[Ivy]<Alpine>Doc>LockDesign0.bravo

XEROX

Attributes:informal, technical, Database, Distributed computing, Filing

References:[Ivy]<Alpine>Doc>LockConcepts0.bravo

Abstract:This memo proposes an interface for the Alpine lock manager.

Introduction

This memo proposes a design for Alpine’s Lock interface. Lock will be used by the implementation of FileStore, and also by applications that perform fine-grained locking and recovery.

Lock: DEFS = BEGIN

LockID: TYPE = RECORD [entity: System.UniversalID, subEntity: SubID];

SubID: TYPE [3];

-- A file is a typical entity; a sub entity of a file is a page, the file’s length, etc. If consecutive pages are represented as consecutive sub entities, then the lock manager may use a run-encoded representation. An application may use the entity field to encode what it thinks of as types: "database record", "index value", etc. The sub entity field must then be used to encode the name of a specific object of that type: a particular record or index value.

-- Since lock mangers are responsible for locking disjoint sets of entities, there is no need for LockIDs to be unique across lock managers, much less across all space and time. They aren’t unique IDs in the strongest sense.

LockMode: TYPE = { R, U, W, IR, IU, IW, RIU, RIW };

-- or something like that ... . R = read, U = update (read and probably convert to write), W = write, I = intention.

Lock: PROC [trans: TransID, lock: LockID, mode: LockMode];

-- Acquire lock, in lock mode mode, for transaction trans. This means (1) wait until request can be granted, (2) acquire lock in mode, (3) increment count associated with [lock, trans]. The wait, if any, will be performed in the lock manager monitor, hence the client may not wish to call Lock with its own monitors locked; see LockNoWait below.

-- <Our goal in designing this procedure should be to isolate the caller as much as possible from all of the things that can go wrong. Some method should be provided to communicate a long lock wait back to the caller - by an informational signal? return code? Will deadlock generate an ERROR?>

LockNoWait: PROC [trans: TransID, lock: LockID, mode: LockMode,
procToCall: PROC [REF ANY], argForProcToCall: REF ANY]
RETURNS [granted: BOOLEAN];

-- Same as Lock, but never waits in lock manager. If lock can be granted without waiting, the lock is granted and the procedure returns TRUE. Otherwise the lock request is queued and the procedure returns FALSE. When the lock is probably available or lock manager times out, the lock request is forgotten and the lock manger calls procToCall[argForProcToCall] with no lock manager monitors locked. (If procToCall = NIL then the reqeust is not queued and procToCall is not called. Otherwise, the idea is that procToCall just reenters whatever monitor is causing us not to use Lock, and notifies the condition variable where we are waiting. Upon getting this notification we can retry our call to LockNoWait.)

Unlock: PROC [trans: TransID, lock: LockID];

-- This means (1) error if trans does not hold lock, (2) decrement count associated with [lock, trans], if count becomes zero then release lock (and consider granting a waiting request).

UnlockTrans: PROC [trans: TransID];

-- This means for all locks held in trans, perform Unlock until count becomes zero (see description of Unlock).

DowngradeTrans: PROC [trans: TransID, downgradeFn: PROC [LockMode] REUTRNS [LockMode]];

-- This means for all locks l held in trans, if downgradeFn[Mode[l]] # Mode[l], then downgrade l to the specified new mode.

END.--Lock