Q 13,paper 3,J 12.Which of the following is scheme to deal with deadlock ?

Option (A) Time out (B) Time in (C) Both (A) & (B) (D) None of the above Answer (A) Another simple approach to deadlock handling is 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. This scheme falls somewhere between deadlock prevention, where a deadlock will never occur and deadlock detection and recovery. Uses of Timeout-Based Schemes
The timeout scheme is particularly easy to implement, and works well if transactions• are short, and if long waits are likely to be due to deadlocks. Limitations • 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.
Other deadlock prevention scheme are. Wait-die If Ti has higher priority, it is allowed to wait; otherwise it is aborted. It means 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). 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. T22 will Wait T24 will rollback
T22 ----------------------> T23 <---------------------- T24
(5) ------------------------- (10) ----------------- (15)
The wait-die scheme is non-preemptive scheme because only a transaction requesting a lock can be aborted. As a transaction grows older (and its priority increases), it tends to wait for more and more younger transactions. Wound-wait If Ti has higher priority, abort Tj otherwise Ti waits. It means 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 (that is Ti is younger than Tj). Otherwise Tj is rolled back (Tj is wounded by Ti). Example: Returning to our previous example, with transactions T22,T23 and T24, ifT22 requests a data item held by T23 then the data item will be preempted from T23 and T23 will be rolled back. IfT24 requests a data item held by T23, and then T24 will wait. This scheme is based on a preemptive technique and is a counterpart to the wait-die scheme. In the wait-die scheme, lower priority transactions can never wait for higher priority transactions. In the wound-wait scheme, higher priority transactions never wait for lower priority transactions. In either case no deadlock cycle can develop. When a transaction is aborted and restarted, it should be given the same timestamp that it had originally. Reissuing timestamps in this way ensures that each transaction will eventually become the oldest transaction, and thus the one with the highest priority, and will get the locks that it requires.