deadlock handling
- 2. DEADLOCK ? WHAT IS DEADLOCK ? CHARACTERISTICS ? HOW TO DEAL SURAJ KUMAR 3MCA-13352230
- 3. DEADLOCK “Deadlock” is a waiting state of a system which never again change because the requested data by the transaction is not available at that time or held by another transaction.
- 4. A system is in a deadlock state if there exists a set of transaction such that every transaction in the set is waiting for another transaction in the set. More precisely there exists a set of waiting transaction {T0,T1,…Tn } such that T0 is waiting for a data item that T1 holds , and T1 is waiting for a data item that T2 holds and …,and Tn-1 is waiting for a data item that Tn hold , and Tn is waiting for a data item that T0 holds . Non of the transactions can make progress in such a situation . The only remedy to this undesirable situation is for the system to invoke some drastic action ,such as rolling back some of the transaction involved in the deadlock Rollback of a transaction may be partial; that is, a transaction may be rolled back to the point where it obtained a lock whose release resolves the deadlock.
- 5. CONDITION FOR DEADLOCK : MUTUAL EXCLUSION HOLD AND WAIT NO PRE-EMPTION CIRCULAR WAIT
- 6. Mutual Exclusion : •At least one data must be held in a non sharable mode •Only one transaction can use the resource at a time •If another transaction requests that data ,it must be delayed until the data has been released
- 7. HOLD AND WAIT : •A transaction must be holding at least one data •waiting to acquire data that are currently being held by other transactions
- 8. No Pre-Emption : •Data can not be pre-empted •Data can be released only completion of transaction
- 9. Circular Wait : •A set of waiting transactions must be exist such that T1 is waiting for T2 , T2 is waiting for T3 and T3 is waiting for T1 •Waiting in a cycle-form
- 10. Methods for dealing with “DEADLOCK “ : •Use some protocol to prevent/avoid deadlocks •Allow the system to enter deadlock state , detect it and then recover •Ignore the problem all together and pretend that deadlocks never occur in the system
- 11. PONDICHERRY UNIVERSITY SURAJ KUMAR (3MCA) WHAT? WHY? HOW?
- 12. Ways of deadlock handling : •AVOIDANCE •PREVENTION •DETECTION AND RECOVERY •Avoidance can be achieved by breaking any of the four reasons of deadlock ,like: •Mutual exclusion,Hold&wait,No pre- emption,Circular wait
- 13. Deadlock prevention : There are three approaches to deadlock prevention – 1.Data locks 2.Transaction rollbacks 3. Timeout-Based Schemes 1. Data locks • Data locks ensures that no cyclic waits can occur . • each transaction locks all its data items before it begins execution. • Moreover, either all are locked in one step or none are locked. Disadvantages – • Before transaction it is hard to predict – what data items need to be locked • since many of the data items may be locked but unused for a long time, data-item utilization may be very low
- 14. 2. Transaction Rollbacks: • Transaction rollback is closer to deadlock recovery • it uses pre-emption and transaction rollback instead of waiting for a lock • In pre-emption , when a transaction T2 requests a lock that transaction T1 holds, the lock granted to T1 may be preempted by rolling back of T1, and granting of the lock to T2. • To control the preemption, we assign a unique timestamp to each transaction. The system uses these timestamps only to decide whether a transaction should wait or roll back. • Locking is still used for concurrency control. If a transaction is rolled back, it retains its old timestamp when restarted. • Two different deadlock prevention schemes using timestamps have been proposed: 2.1 wait-die scheme 2.2 wound-wait scheme
- 15. 2.1 The wait–die scheme This is a non-preemptive technique. When transaction Ti requests a data item currently held by Tj , Ti is allowed to wait only if it has a timestamp smaller than that of Tj (that is, Ti is older than Tj ). Otherwise, Ti is rolled back (dies). For example, suppose that transactions T22, T23, and T24 have timestamps 5, 10, and 15, respectively. If T22 requests a data item held by T23, then T22 will wait. If T24 requests a data item held by T23, then T24 will be rolled back. The wound–wait scheme is a preemptive technique. It is a counterpart to the wait–die scheme. When transaction Ti requests a data item currently held by Tj , Ti is allowed to wait only if it has a timestamp larger than that of Tj (I,e , Ti is younger than Tj ). Otherwise, Tj is rolled back (Tj is wounded by Ti). Returning to our example, with transactions T22, T23, and T24, if T22 requests a data item held by T23, then the data item will be pre-empted from T23, and T23 will be rolled back. If T24 requests a data item held by T23, then T24 will wait. The major problem with these schemes is that unnecessary rollbacks may occur. 2.2 The wound-wait scheme
- 16. 3. Timeout-Based Schemes: • This is a simple approach based on lock timeouts. • In this approach, a transaction that has requested a lock waits for at most a specified amount of time. • If the lock has not been granted within that time, the transaction is said to time out, and it rolls itself back and restarts. • If there was in fact a deadlock, one or more transactions involved in the deadlock will time out and roll back, allowing the others to proceed. • The timeout scheme is particularly easy to implement, and works well if transactions are short . Disadvantages - • Generally, it is hard to decide how long a transaction must wait before timing out. • Too long a wait results in unnecessary delays once a deadlock has occurred. • Too short a wait results in transaction rollback even when there is no deadlock, leading to wasted resources. • Starvation is also a possibility with this scheme. Hence, the timeout-based • scheme has limited applicability.
- 17. Deadlock Detection and Recovery: If a system does not employ some protocol that ensures deadlock freedom, then a detection and recovery scheme must be used. Detection examines the system that a deadlock has occurred or not. If one has, then the system must attempt to Recover from the deadlock. To do so, the system must: • Maintain information about the current allocation of data items to transactions, as well as any outstanding data item requests. • Provide an algorithm that uses this information to determine whether the system has entered a deadlock state. • Recover from the deadlock when the detection algorithm determines that a deadlock exists.
- 18. 1.Deadlock detection: • Deadlock detection examines the system to determine whether a deadlock has occurred or not . • It uses a variant of resource-allocation graph , known as “wait-for graph” • This graph consists of a pair G=(V,E), where v is the set of vertices and E is the set of edges. • Vertices consist of transactions ,while edges are the ordered pair of transactions • A deadlock exists in the system if and only if the wait-for graph contains a cycle. • Each transaction involved in the cycle is said to be deadlocked. To detect deadlocks, • the system needs to maintain the wait-for graph, and periodically to invoke an algorithm that searches for a cycle in the graph.
- 19. consider the wait-for graph in Figure, which depicts the following situation: • Transaction T25 is waiting for transactions T26 and T27. • Transaction T27 is waiting for transaction T26. • Transaction T26 is waiting for transaction T28. • Transaction T28 is waiting for transaction T27. Since the graph has a cycle, the system is in a deadlock state .
- 20. 2.Deadlock Recovery: If deadlock exists, the most common solution is to rollback one or more transactions to break the deadlock. Three actions need to be taken: 1. Selection of a victim 2. Rollback 3. Starvation 2.1 Selection of a Victim- we must determine which transaction (or transactions) to roll back to break the deadlock. We should roll back those transactions that will incur the minimum cost. I,e – How long the transaction has computed, How many more data items the transaction needs for it to complete, How many data items the transaction has used, How many transactions will be involved in the rollback.
- 21. 2.2 Rollback- once we have decided that a particular transaction must be rolled back, we must determine how far this transaction should be rolled back. Total Rollback: this is simplest solution to Abort the transaction and then restart it. partial rollback: it is more effective to roll back the transaction only as far as necessary to break the deadlock. 2.3 Starvation- In a system where the selection of victims is based primarily on cost factors, it may happen that the same transaction is always picked as a victim. As a result, this transaction never completes its designated task, thus there is starvation. We must ensure that transaction can be picked as a victim only a (small) finite number of times. The most common solution is to include the number of rollbacks in the cost factor.