Scribd
Upload
34 views13 pages

Chapter 05 Dead Lock

Uploaded by

Piyumi Sandareka
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
34 views13 pages

Chapter 05 Dead Lock

Uploaded by

Piyumi Sandareka
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Chapter 05 – Part 03

Deadlocks
Deadlock
 A deadlock is a situation in which two or more competing
actions are each waiting for the other to finish, and thus neither
ever does.
Deadlock occurs when each transaction T in a set of two or
more transactions is waiting for some item that is locked by
some other transaction T′ in the set. Hence, each transaction in
the set is in a waiting queue,
 Suppose we have the following scenario:
• T1 asks for an exclusive lock on A
• T2 asks for an exclusive lock on B
• T1 asks for a shared lock on B
• T2 asks for a shared lock on A
 Both T1 and T2 are waiting! We have a DEADLOCK.
3 Deadlock - Examples
4
Deadlock Management
5

 Deadlock Detection and resolution


• Detect with Wait-For-Graph (WFG)
• Victim Selection
• Timeouts
 Deadlock Prevention
• Conservative 2PL
• Transaction prioritization
Wait-For-Graph (WFG)
6
 A graph with nodes and edges
 Node represents a transaction
 Edge from Ti to Tj means that Ti is waiting for
transaction Tj to release a lock
 A deadlock occurs if and only if the WFG has a cycle
7 Wait-For-Graph (2)
8 Deadlock example
Victim Selection
9

 With the help of some relative algorithm, a transaction is


chosen, which is to be aborted. This transaction is known as
the victim and the process is known as victim selection.
 May cause starvation
 Starvation – A transaction is repeatedly aborted in favor
of other transactions
Conservative 2PL
10

 Transactions obtain all the locks they need before the


transactions begin.
 If cannot get them die and retry
 This is to ensure that a transaction that already holds
some locks will not block waiting for other locks.
Transaction Prioritization
11
 Assign a priority to each transaction and avoid potential
deadlocks by aborting transactions with lower priorities
 One priority implementation is to use the start time (timestamp) of
each transaction. Timestamp is a unique identifier assigned to
each transaction.
 The timestamps are typically based on the order in which
transactions are started;
 if transaction T1 starts before transaction T2, then TS(T1) < TS(T2).
 ##Notice that the older transaction (which starts first) has the
smaller timestamp value

 Two possible rules for choosing a transaction to abort


 Wait-Die Rule
 Wound – Wait Rule
Wait – Die Rule
12

 If a transaction requests to lock a resource (data item),


which is already held with a conflicting lock by another
transaction, then one of the two possibilities may occur

 If TS(Ti) < TS(Tj) − that is Ti, which is requesting a


conflicting lock, is older than Tj − then Ti is allowed to
wait until the data-item is available.

 If TS(Ti) > TS(Tj) − that is Ti is younger than Tj − then


Ti dies. Ti is restarted later with a random delay but with
the same timestamp.
 This scheme allows the older transaction to wait but kills
the younger one.
Wound – Wait Rule
13

 If a transaction requests to lock a resource (data item),


which is already held with conflicting lock by some
another transaction, one of the two possibilities may occur
 If TS(Ti) < TS(Tj), then Ti forces Tj to be rolled back − that is
Ti wounds Tj. Tj is restarted later with a random delay
but with the same timestamp.
 If TS(Ti) > TS(Tj), then Ti is forced to wait until the resource
is available.
 This scheme, allows the younger transaction to wait; but
when an older transaction requests an item held by a
younger one, the older transaction forces the younger one
to abort and release the item.

You might also like