Chapter 8 Lock Implementation COP 6730 1 Lock

  • Slides: 25
Download presentation
Chapter 8 Lock Implementation COP 6730 1

Chapter 8 Lock Implementation COP 6730 1

Lock Implementation • Locks record all the current requests, either granted or waiting, for

Lock Implementation • Locks record all the current requests, either granted or waiting, for a named resource. • They are a simple data structure with two basic operations: lock() and unlock(), along with support operations. 2

Lock Names Each lock has a name typedef struct { /* definition for lock

Lock Names Each lock has a name typedef struct { /* definition for lock name */ RMID rmid /* resource manager id */ char resource [14] /* object name is 14 bytes */ }lock_name; • RM ID in each lock name is to allow RMs to have disjoint sets of locks and to pick lock names at will from their own name spaces. • We would like the object names to be of unlimited length, but for performance reasons, they are usually limited to a small, fixed length. – Above definition suggests object names fit in 14 characters – In general, each RM must hash long object names into this smaller unit. If two objects hash to the same lock name, and the two request modes are incompatible, then the collision may 3 cause spurious waits.

Group Mode Each granted group has a summary mode that is the maximum of

Group Mode Each granted group has a summary mode that is the maximum of the modes of the group members. Lock Conversion Lattice • Initial state: Group Mode • After the IX mode request is unlocked: 4

Lock Conversion • A conversion needs to wait until the converted mode is compatible

Lock Conversion • A conversion needs to wait until the converted mode is compatible with all requests granted to other transactions • When conversions are waiting, no new members are admitted to the granted group until all conversions have been granted No new members are admitted 5

Lock Conversion Examples /* The IX lock requests a lock conversion to S */

Lock Conversion Examples /* The IX lock requests a lock conversion to S */ /* SIX is compatible with IS */ /* IX is incompatible with SIX */ /* The conversion is still waiting */ /* SIX lock is released, and the conversion is granted 6 */

Lock Class • Each lock is requested and held in some class. • Instant,

Lock Class • Each lock is requested and held in some class. • Instant, short, long are examples of classes: Instant: The lock operation immediately calls unlock on requests that are acquired for instant duration. Short: The lock is released at the end of a particular operation. long: The lock is held to transaction commit. 7

Lock Class • The class names are represented as integers and are accordingly ranked:

Lock Class • The class names are represented as integers and are accordingly ranked: longer duration locks have larger class numbers. • If a lock is held in one class and requested in a second, then the resulting class is the max of the two (class escalation). • Most of the lock classes are understood only by the RMs. 8

Lock Manager: lock • A lock request specifies a lock name, a mode, a

Lock Manager: lock • A lock request specifies a lock name, a mode, a class, and a timeout for waits. lock_reply lock ( lock_name, lock_mode, lock_class, long timeout); • The lock request returns either OK, timeout, or deadlock. If it returns OK, the lock was acquired. 9

Lock Manager: unlock_reply unlock_name (lock_name); lock_reply unlock_class (lock_class Boolean all_le, RMID rmid); § The

Lock Manager: unlock_reply unlock_name (lock_name); lock_reply unlock_class (lock_class Boolean all_le, RMID rmid); § The all_le parameter is a Boolean and used to control unlocking of all classes below the specified class § The unlock can be restricted to a particular RM if the rmid is nonzero. 10

Lock Manager: Data Structure Locked object Hash chain 11

Lock Manager: Data Structure Locked object Hash chain 11

Lock Manager: Data Structure (Cont’d) • Adding a new locked object (lock header) to

Lock Manager: Data Structure (Cont’d) • Adding a new locked object (lock header) to the hash chain requires getting the semaphore on the hash chain. • Adding a new lock request to a lock queue requires only the semaphore on the lock queue. • The lock header free pool is a preallocated and preformatted pool of blocks for quick allocation. • A similar lock request pool is also maintained. • The transaction lock list is used to accelerate generic unlock operations (e. g. releasing all locks at transaction commit). 12

Transaction Commit Two strategies for releasing locks: 1. Each RM can use the generic

Transaction Commit Two strategies for releasing locks: 1. Each RM can use the generic unlock routine to ask the lock manager to release all the RM’s locks for that transaction. This approach gives the RM more control. 2. The lock manager can join the transaction and thereby get prepare, commit, and abort callbacks from the TM when the transaction changes state. This approach provides a simpler interface to the resource manager. 13

Transaction Commit (Cont’d) Strategy #1 Strategy #2 RM 1 Lock Manager RM 2 RM

Transaction Commit (Cont’d) Strategy #1 Strategy #2 RM 1 Lock Manager RM 2 RM 3 RM 1 TM RM 2 TM RM 3 Lock Manager 14

Transaction Savepoints At each savepoint, it is necessary to save the transaction state so

Transaction Savepoints At each savepoint, it is necessary to save the transaction state so that the state can be restored later. From a locking perspective, this state restoration consists of: 1. unlocking resources acquired since the savepoint, and 2. reacquiring locks released since the savepoint 15

Transaction Savepoints (Cont’d) • Unlocking resources acquired since the savepoint § Insert a dummy

Transaction Savepoints (Cont’d) • Unlocking resources acquired since the savepoint § Insert a dummy lock request block in the transaction lock list at each savepoint. § After rollback to a savepoint, all locks after the dummy lock request block in the transaction lock list are released. • Reacquiring locks released since the savepoints. § The lock manager writes a log recording all the locks held by the transaction at the current savepoint. 16

Deadlock Detection: The Idea 1. The algorithm takes each node (transaction), in turn, as

Deadlock Detection: The Idea 1. The algorithm takes each node (transaction), in turn, as the root of what it hopes will be a tree (i. e. , no cycles), and does a depth-first search on it. 2. If it ever comes back to a node it has already encountered, then it has found a cycle 3. If it exhausts all the arcs from any given node, it backtracks to the previous node. 4. If it backtracks to the root and cannot go further, the subgraph reachable from the current node does not contain any cycles. 5. If property 4 is true for all nodes (transactions), the entire graph is cycle free, so the system is not deadlock. 17

Deadlock Detection Algorithm Data Structure: L = a list of nodes (transactions). Algorithm: For

Deadlock Detection Algorithm Data Structure: L = a list of nodes (transactions). Algorithm: For each node, N, in the graph, perform the following 5 steps with N as the starting node. 1. Initialize L to the empty list, and designate all the arcs as unmarked. 2. Add the current node to the end of L and check to see if the node now appears in L two times. If it does, the graph contains a cycle (listed in L) and the algorithm terminates. 3. From the given node, see if there any unmarked outgoing arcs. If so, go to step 4; else, go to step 5. 18

Deadlock Detection Algorithm (Cont’d) 4. Pick an unmarked outgoing arc at random and mark

Deadlock Detection Algorithm (Cont’d) 4. Pick an unmarked outgoing arc at random and mark it. Then follow it to the new current node and go to step 2. 5. We have now reached a dead end. – Remove the current node from L, and go back to the previous node, that is, the one that was current just before this one, make that one the current node. – If the new current node is the initial node, the subgraph does not contain any cycles; otherwise, go to step 2. 19

Deadlock Detection: Examples • The tree rooted at T 1 (formed by depth-first search)

Deadlock Detection: Examples • The tree rooted at T 1 (formed by depth-first search) has no cycle: L = T 1 Þ T 1 is not involved in a dead lock. • The “tree” rooted at T 6 contains a cycle: L = [ T 6, T 3, T 7, T 11, T 7 ] a cycle T 6 Þ a deadlock is detected. Þ either T 7 or T 11 must be rollbacked. T 12 T 7 T 1 T 8 T 3 T 2 T 4 T 5 T 9 T 11 T 10 20

Distributed Deadlock Detection • When a transaction is blocked, it sends a special probe

Distributed Deadlock Detection • When a transaction is blocked, it sends a special probe message to the blocking transaction. The message consists of three numbers: 1. the transaction that just blocked, 2. the transaction sending the message, 3. and the transaction to whom it being sent. • When the message arrives, the recipient checks to see if itself is waiting for any transaction. If so, – the message is updated, replacing the second field by its own TID and the third one by the TID of the transaction it is waiting for. – The message is then sent to the blocking transaction. • If a message goes all the way around and come back to the original sender, a deadlock is detected. 21

Distributed Deadlock Detection Example (0, 8, 0) 4 0 (0, 4, 6) 6 8

Distributed Deadlock Detection Example (0, 8, 0) 4 0 (0, 4, 6) 6 8 (0, 0, 1) 3 1 (0, 1, 2) 2 (0, 2, 3) Machine 0 5 Machine 1 (0, 5, 7) 7 Machine 2 22

Distributed Deadlock Resolution Strategy 1: Has the transaction that initiated the probe commit suicide.

Distributed Deadlock Resolution Strategy 1: Has the transaction that initiated the probe commit suicide. Problem: If several transactions involved in the same cycle simultaneously invoke the algorithm, then each would eventually discover the deadlock, and each would kill itself. 23

Distributed Deadlock Resolution Strategy 2: Have each transaction adds its TID to the end

Distributed Deadlock Resolution Strategy 2: Have each transaction adds its TID to the end of the probe message, so that when it returned to the initial sender, the complete cycle would be listed. The sender can then request the transaction with the largest TID (youngest) to kill itself. Note: If multiple transactions discover the same cycle at the same time, they will all choose the same victim. 24

Complexities • A real deadlock detector handling all the cases would be about 200

Complexities • A real deadlock detector handling all the cases would be about 200 lines of code. • The whole body of a lock manager (including a deadlock detector) typically comes to about 1000 lines of code. 25