chapter 8 lock implementation l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 8 Lock Implementation PowerPoint Presentation
Download Presentation
Chapter 8 Lock Implementation

Loading in 2 Seconds...

play fullscreen
1 / 25

Chapter 8 Lock Implementation - PowerPoint PPT Presentation


  • 289 Views
  • Uploaded on

Chapter 8 Lock Implementation. COP 6730. 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. Lock Names.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 8 Lock Implementation' - paul


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
lock implementation
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.
lock names
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 cause spurious waits.
group mode
Group Mode

Each granted group has a summary mode that is the maximum of the modes of the group members.

  • Initial state:
  • After the IX mode request is unlocked:

Lock Conversion Lattice

Group Mode

lock conversion
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

lock conversion examples
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 */

lock class
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.

lock class8
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.
lock manager lock
Lock Manager: lock
  • A lock request specifies a lock name, a mode, a class, and a timeout for waits.

lock_reply lock ( lock_name name,

lock_mode mode,

lock_class class,

long timeout);

  • The lock request returns either OK, timeout, or deadlock. If it returns OK, the lock was acquired.
lock manager unlock
Lock Manager: unlock

lock_reply unlock_name(lock_namename);

lock_reply unlock_class(lock_class 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.
lock manager data structure
Lock Manager: Data Structure

Locked

object

Hash

chain

Locked

object

lock manager data structure cont d
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 pre-formatted 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).
transaction commit
Transaction Commit

Two strategies for releasing locks:

  • 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.

  • 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.

transaction commit cont d
Strategy #2

Strategy #1

Transaction Commit (Cont’d)

RM1

RM1

TM

TM

Lock

Manager

RM2

RM2

RM3

RM3

Lock

Manager

transaction savepoints
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:

  • unlocking resources acquired since the savepoint, and
  • reacquiring locks released since the savepoint
transaction savepoints cont d
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 record recording all the locks held by the transaction at the current savepoint.
deadlock detection the idea
Deadlock Detection: The Idea
  • 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.
  • If it ever comes back to a node it has already encountered, then it has found a cycle
  • If it exhausts all the arcs from any given node, it backtracks to the previous node.
  • If it backtracks to the root and cannot go further, the subgraph reachable from the current node does not contain any cycles.
  • If property 4 is true for all nodes (transactions), the entire graph is cycle free, so the system is not deadlock.
deadlock detection algorithm
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.

  • Initialize L to the empty list, and designate all the arcs as unmarked.
  • 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.
  • From the given node, see if there are any unmarked outgoing arcs. If so, go to step 4; else, go to step 5.
deadlock detection algorithm cont d
Deadlock Detection Algorithm (Cont’d)
  • Pick an unmarked outgoing arc at random and mark it. Then follow it to the new current node and go to step 2.
  • 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.
deadlock detection examples
Deadlock Detection: Examples
  • The tree rooted at T1 (formed by depth-first search) has no cycle:

L =  T1 

    • T1 is not involved in a dead lock.
  • The “tree” rooted at T6 contains a cycle:

L = [ T6, T3, T7, T11, T7 ]

    • a deadlock is detected.
    • either T7 or T11 must be rollbacked.

a cycle

T6

T12

T7

T1

T11

T8

T3

T2

T10

T9

T4

T5

distributed deadlock detection
Distributed Deadlock Detection
  • When a transaction is blocked, it sends a special probe message to the blocking transaction. The message consists of three numbers:
    • the transaction that just blocked,
    • the transaction sending the message,
    • 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.
distributed deadlock detection example
Distributed Deadlock DetectionExample

(0, 8, 0)

(0, 4, 6)

6

8

4

0

(0, 0, 1)

3

1

(0, 1, 2)

(0, 5, 7)

5

7

2

(0, 2, 3)

Machine 2

Machine 1

Machine 0

distributed deadlock resolution
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.

distributed deadlock resolution24
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.

complexities
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.