Object Lock Management
6.1. Controlling Concurrent Access
-(j
o
C)
Chapter 6
Object Lock Management
The AEGIS system on every node runs a lock manager that provides rtle system clients with the ability to control simultaneous access to objects. Using the lock manager, a process can gain control of an object, then block other processes Crom using the object in an incompatible way.
Both . user-mode and supervisor-mode AEGIS components rely on the lock manager whep accessing obje~ts.
The AEGIS system locking mechanism is designed to solve two problems:
• To control concurrent access to an object; that is, to provide orderly access to the data so that, when two processes modiry the same object, their modifications do Dot simultaneously overwrite each other .
• To maintain consistent data between the caches in all nodes; that is, to ensure that all processes in the distributed system have the same view or an object.
The next sections explain how the lock manager handles concurrent access and maintains cache consisten cy .
6.1.
Controlling Concurrent Access
The kinds of access that the lock manager permits depends on the object's concurrency mode, its access mode, and its lock key.
6.1.1. Concurrency Mode
The AEGIS system defines three concurrency modes that a process can apply to an object:
• No concurrency control
• Protected concurrency control, which allows shared reading or exclusive writing (file_$nr _xor _lw)
• Shared concurrency control, which allows shared writin~ (file _ $cowriters) 6.1.1 .. 1. No Concurrency Control
An object that the FILE manager creates has the rollowing characteristics:
• It is a temporary object.
• It is uncatalogued; that is, it has no associated pathname entry in the naming server's directory structure.
• It has no concurrency control assigned; that is, anyone in the distributed system can potentially read and write it.
6-1 Obiect Lock Management
The object's creator is responsible ror making the object permanent, cataloguing it, and assigning it another concurrency mode. Some objects, however, remain temporary and un catalogued because their creators do not intend to share them with other processes. Because they are not shared, these objects do not need any concurrency control; ror example, thePROC2 manager does not apply concurrency control to the stack object, because only one process uses it exclusively.
8.1.1.2. Protected Concurrenq Control
Protected concurrency mode (nr _xor _Iw) synchronizes access to an object at the process level.
Protected concurrency control means that either any number or processes can read the object, and writing is blocked, or only one process can write the object, and all readers are blocked.
8.1.1.S. Shared ConcurrenC7 Control
Shared concurrency control (cowriters) allows any number or processes to simultaneously write an object, but all the writing processes must be running on the same node; the object, however, can reside on a different node than the processes that are rererencing it. Consequently, the cowriters type of concurrency provides protected concurrency mode (nr _xor _lw) access to objects at the node level: any number or nodes can read the object, and writing is blocked, or one node can write the object, and all readers are blocked.
8.1.2. Access Mode
When a process locks an object, it specifies, in addition to the object's concurrency mode, the way it wants to access the object; this is the lock's access mode. The lock manager supports three types of access (or protected and shared locks: read, write, and read with intent to write at a later time (RIW). (Note that it does not support write with intent to read at a later time.)
In addition~ processes can direct the lock manager to change (rom one access mode to another:
change read to write, change read to RIW, and so on. The hierarchy of access modes and change access mode requests (from weakest to strongest) is as rollows:
1. All (used on unlock only) 2. Read
3. Read with intent to write (RIW) 4. Change read to write
5. Write
6. Change write to read 7. Change read to RIW 8. Change write to RIW 9. Mark (or deletion 10. Unmark (or deletion
06jeet Lock Management 8-2
' ... , .'
o
o
o
Mark for delete is not really an access mode. Rather, when set, it directs the lock manager on the home node to delete the object as lOOn as it has released the last lock held on it. The system -locks· temporary objects with the mark-ror-delete access mode to enrorce automatic resource cleanup during process deletion. The PROC2 manager's delete operation releases all locka that the target. process holds; consequently, the lock release will trigger the object deletion (which the AST manager &st _ .truncate routine carries out).
8.1.1. Lock Compatlbll1t7
Before the lock manqer CaD srant a lock to a process, the requested lock must be eotnptJti6le with the other locka held OD the object. The compatibility rules are:
• Shared reads and protected reads are compatible and can originate rrom difl'erent
. Protected Protected Exclusive Shared
R RIW W R write lock. One protected write lock, however, blocks any other writers or readers.
8-3 Object Lock Management
On the other hand, iC a process holds a shared read lock, any process on the ,ame node can simultaneously hold a shared write lock. As a result, holding a shared read lock does not bar other proct"sses Crom getting a shared write lock and changing the object. It is up to the application using the shared concurrency mode to control concurrent access between the processes on that node.
In addition, the lock manager permits protected reads ·4 occur simultaneously with shared reads, as long as there are no unregulated write locb on the object.
8.1.4. The Loc:k Table
The lock manager on each node maintains a lock table that records:
• All locks on local objects, whether they are held by local or remote processes
• All locks held by local processes, whether they lock remote objects or local objects
Consequently, when a process requests and obtains a lock on a remote object, two lock tables are updated: the table on the object's home node reflects the Cact that the local object is locked, whereas the table on the calling process's node indicates that the process holds a lock. Lock tables never store information about remote processes holding remote locks; either the process or
the object must be local. .
The information stored in the lock table entry includes:
• The locked object's network number and UID.
• The locking process's network number and UID.
• The lock's concurrency mode (protected or shared) and access mode (read, write, or RIW).
• The transaction ID, which identifies individual lock requests in the event that a single - process locks the same object more than once. The lock manager also uses the transaction ID to identify duplicate lock operations. On lock requests, the duplicate lock transaction ID will match the existing lock, 80 the lock manager can discard the duplicate. On unlock requests, the lock will no longer be recorded in the lock table.
• Whether or not it is marked Cor delete; only the lock table on the object's home node will indicate mark-Cor-delete status.
The object UID, process UID, and transaction II> together define a lock's uniqueness.
Obiect Lor.k Management 8-4
c
(j
8.1.5. Lock Key
In addition to the lock entries in the lock table, the cached and local object storage systems (AST and VTOe) provide a lock key field that reflects how the object is locked. The field can contain anyone of the following values:
• If the lock key field is 1, there is no concurrency control on the object. This key allows any node to read or write the object (any access lock key).
• If the lock key. field is 0, the object is locked for reading only (there are no writers).
This key allows any node to read the object (all readers lock leey).
• If the lock key field contains a node ID, the object is locked Cor protected or shared write. The node ID in the lock key corresponds to the process that has locked the object for write. This key prevents processes on other nodes Crom reading or writing the object.
The lock key provides cached concurrency control. The system uses the key to enforce the locks that processes have obtained and stored in the lock table. Specifically, the AST manager on the object's home node checks this field when it is called to process remote read or write requests for the object's pages (ast_Stouch). On a remote request to read a page, the home node checks the lock key and permits the read if:
• The lock key is all readers
• The lock key is any access
• The node ID of the reader matches the node ID in the lock key (shared reads and writes can occur simultaneously, but they must originate from the same node)
If the lock key and request are not compatible, the cached OSS reports a read concurrency violation.
If the remote request is to write a page, the write is permitted if one of the following conditions is met:
• The lock key says any access
• The node ID of the writer matches the node ID in the lock key Otherwise, the system issues write concurrency violation status.
The lock key check enforces the lock in two ways. First, it ensures that the locking process cannot carry out an an illegal operation under the lock, like writing the object when it has locked it for read access. Second, it ensures that other processes will not break the locking process's lock as it is recorded in the lock table.
Storing the object's lock key in the ASTE also optimizes page I/O, because it allows the system to determine quickly whether or not the requested paging operation is legal.
8-5 Obiect Lock Management
6.1.8. Obf.aining a Lock
A process that wants to lock an object makes a lock request to the lock manager, specifying the object's UID, the concurrency mode to assign, and the way it wants to access the object (R, W, RIW). "'''hen it receives the request, the lock manager checks its lock table to determine whether the proce&! is allowed to lock the object; that is, whether the lock request is compatible with the other locks stored in the table. Because locb with different concurrency modes are compatible, the lock manager must scan the entire chain of locb for an object to make sure that the requested Jock is compatible with every other lock held.
If the requested lock is compa.tible, the lock manager grants the lock by creating a new lock entry for the object in the lock table. In addition, it the lock key required by the new lock is different from the lock key cached in the object's active segment table entry (that is, if an ASTE for the object exists), the lock manager writes the new lock key into the ASTE. If the object is local, the AST manager will write it through to the VTOCE.
8:1.7. Changing a Lock'. Access Mode
A process· can change the access mode of an existing lock. The lock mana.ger follows the exclusive or rule when handling requests to change the access mode of an existing lock:
• If the existing lock is a protected read, the caller can change it to a write lock as long as there are no other readers.
• If the existing lock is a protected write, the caller can always change to a read lock.
A process can only change the access mode of an existing lock; it cannot change its concurrency mode.