0% found this document useful (0 votes)
20 views

Unit 4_Deadlock Handling

Uploaded by

omvati343
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
20 views

Unit 4_Deadlock Handling

Uploaded by

omvati343
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

Department of Information Technology

Deadlock Management
Outline
 Deadlock Management
 Deadlock Prevention
 Deadlock Avoidance
 Deadlock Detection & Resolution
 Centralized Deadlock Detection
 Hierarchical Deadlock Detection
 Distributed Deadlock Detection
Deadlock Management
 Deadlock
is a permanent phenomenon. If one exists in a system, it will not go away
unless outside intervention takes place. This outside interference may
come from the user, the system operator, or the software system (the
operating system or the distributed DBMS). A deadlock can occur
because transactions wait for one another and occurs when the WFG
contains a cycle.
 Deadlock: Necessary Conditions
‰For a deadlock to occur, each of the following four conditions must hold.
 Mutual Exclusion
 Hold and Wait
 No Preemption
 ™Circular Wait
Deadlock Management
 wait-for graph(WFG)
A useful tool in analyzing deadlocks is a wait-for graph (WFG). A WFG is a directed
graph that represents the wait-for relationship among transactions. The nodes of
this graph represent the concurrent transactions in the system. An edge Ti ! Tj
exists in the WFG if transaction Ti is waiting for Tj to release a lock on some
entity .

We should indicate that the formation of the WFG is more complicated in distributed
systems, since two transactions that participate in a deadlock condition may be
running at different sites. We call this situation a
global deadlock. In distributed systems, then, it is not sufficient that each local
distributed DBMS form a
local wait-for graph (LWFG) at each site; it is also necessary to form a global wait-for
graph (GWFG), which is the union of all the LWFGs.
Deadlock Management
 Difference between LWFG and GWFG
Assume T1 and T2 run at site 1, T3 and T4 run at site 2. Also assume T3 waits for a lock
held by T4 which waits for a lock held by T1 which waits for a lock held by T2
which, in turn, waits for a lock held by T3.

 Methods for handling Deadlock


There are three known methods for handling deadlocks: prevention, avoidance, and
detection and resolution.
Of course, there is a fourth alternative that the system ignore deadlocks and require either that the
application in programmer deal with it or that the system be restarted.
However, we obviously do not consider this to be a serious alternative.
Deadlock Prevention
 Guarantee that deadlocks cannot occur.
 the transaction manager checks a transaction when it is first initiated
and does not permit it to proceed if it may cause a deadlock.
 The transaction manager reserves all the data items that are
predeclared by a transaction that it allows to proceed.
 Unfortunately, such systems are not very suitable for database
environments.
 Suitable for systems that have no provisions for undoing processes.
 Advantage :
 Reduce concurrency.
 Additional overhead in evaluating whether a transaction can proceed safely.
 No run-time support which reduce the overhead.
 Not necessary to abort and restart a transaction due to deadlocks.
Deadlock Avoidance
 There’s two cases will consider
 Employ concurrency control techniques that will never result in deadlocks.
 Require that potential deadlock situations are detected in advance and
steps are taken such that they will not occur.
 The simplest means of avoiding deadlocks is to order the resources
and insist that each process request ccess to these resources in that
order, This ordering of lock units may be done either globally or locally
at each site.
 It is also necessary to order the sites and require that transactions
which access data items at multiple sites request their locks by visiting
the sites in the predefined order.
 Deadlock avoidance methods are more suitable than prevention
schemes for database environments. Their fundamental drawback is
that they require run-time support for deadlock management, which
adds to the run-time overhead of transaction execution.
 Add run-time overhead of transaction execution cause fundamental
drawback.
Deadlock Avoidance
 Examples of Deadlock Avoidance approaches is the WAIT-DIE
and WPUND-WAIT algorithms, these algorithms based on the
assignment of timestamps to transaction time.
 WAIT-DIE algorithm :-
If Ti requests a lock on a data item which is already locked by Tj, then Ti is
permitted to wait iff ts(Ti)<ts(Tj). If ts(Ti)>ts(Tj ), then Ti is aborted and
restarted with the same timestamp.

 if ts(Ti)<ts(Tj ) then Ti waits else Ti dies


 non-preemptive: Ti never preempts Tj
 prefers younger transactions

 WPUND-WAIT algorithms
If Ti requests a lock on a data item which is already locked by Tj , then Ti is permitted to wait
iff ts(Ti)>ts(Tj). If ts(Ti)<ts(Tj), then Tj is aborted and the lock is granted to Ti.

 if ts(Ti)<ts(Tj ) then Ti waits else Ti dies


 non-preemptive: Ti never preempts Tj
 prefers younger transactions
Deadlock Detection and Resolution
 Deadlock detection and resolution is the most popular and
best-studied method.
 Resolution of deadlocks is typically done by the selection of one or
more victim transaction(s) that will be preempted and aborted in order
to break the cycles in the GWFG.
 Under the assumption that the cost of preempting each member of a
set of deadlocked transactions is known, the problem of selecting the
minimum total-cost set for breaking the deadlock cycle has been shown
to be a difficult (NP-complete) problem .
 There are some factors that affect this choice :-
 The amount of effort that has already been invested in the transaction.
 The cost of aborting the transaction.
 The amount of effort it will take to finish executing the transaction.
 The number of cycles that contain the transaction.
 There are three fundamental methods of detecting distributed
deadlocks, referred as centralized, distributed, and hierarchical
deadlock detection.
Centralized Deadlock Detection
 One site is designated as the deadlock detector for the system.
Each scheduler periodically sends its local WFG to the central
site which merges them to a global WFG to determine cycles.
 The length of intervals for transmitting this information is a
system design decision: the smaller the interval, the smaller
the delays due to undetected deadlocks, but the larger the
communication cost.
 Centralized deadlock detection has been proposed for
distributed INGRES. This method is simple and would be a very
natural choice if the concurrency control algorithm were
centralized 2PL.
 However, the issues of vulnerability to failure, and high
communication overhead, must also be considered.
Hierarchical Deadlock Detection
 An alternative to centralized deadlock detection is the building
of a hierarchy of deadlock detectors.
 The hierarchical deadlock detection method reduces the
dependence on the central site, thus reducing the
communication cost.
 however, considerably more complicated to implement and
would involve non-trivial modifications to the lock and
transaction manager algorithms.
Distributed Deadlock Detection
 Sites cooperate in detection of deadlocks.
 Each local deadlock detector
 looks for a cycle that does not involve the external edge. If
it exists, there is a local deadlock which can be handled
locally.
 looks for a cycle involving the external edge. If it exists, it
indicates a potential global deadlock. Pass on the
information to the next site.

 We therefore briefly outline that method, basing the discussion on The


LWFG at each site is formed and is modified as follows:
 Since each site receives the potential deadlock cycles from other sites, these
edges are added to the local WFGs.
 The edges in the local WFG which show that local transactions are waiting for
transactions at other sites are joined with edges in the local WFGs which show
that remote transactions are waiting for local ones.
Thank You…

You might also like