Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the difference between "wait-die" and "wound-wait" deadlock prevention algorithms?

What is the difference between wait-die and wound-wait algorithms?

It seems that both of these deadlock prevention techniques are doing the same thing: A Rollback of older process.

What is the difference between the two?

Please provide a suitable example to contrast the two algorithms.

like image 814
Nadeem Bhati Avatar asked Sep 26 '15 05:09

Nadeem Bhati


People also ask

What is deadlock prevention explain Wait-die and wound-wait for deadlock prevention?

Deadlock prevention mechanism proposes two schemes : Wait-Die Scheme – In this scheme, If a transaction requests a resource that is locked by another transaction, then the DBMS simply checks the timestamp of both transactions and allows the older transaction to wait until the resource is available for execution.

Is wound-wait preemptive?

(A) Wound-Wait is a preemptive technique for deadlock prevention. 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 (i.e. Tj is younger than Ti), otherwise, Ti is wounded by Tj.

What is deadlock explain any two methods to prevent deadlock?

Deadlock can be prevented by eliminating any of the four necessary conditions, which are mutual exclusion, hold and wait, no preemption, and circular wait. Mutual exclusion, hold and wait and no preemption cannot be violated practically. Circular wait can be feasibly eliminated by assigning a priority to each resource.


1 Answers

Wait-Die scheme

It is a non-preemptive technique for deadlock prevention. When transaction Tn requests a data item currently held by Tk, Tn is allowed to wait only if it has a timestamp smaller than that of Tk (That is Tn is older than Tk), otherwise Tn is killed ("die").

In this scheme, 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:

  1. Timestamp(Tn) < Timestamp(Tk) − that is Tn, which is requesting a conflicting lock, is older than Tk − then Tn is allowed to "wait" until the data-item is available.

  2. Timestamp(Tn) > Timestamp(Tk) − that is Tn is younger than Tk − then Tn is killed ("dies"). Tn is restarted later with a random delay but with the same timestamp(n).

This scheme allows the older transaction to "wait" but kills the younger one ("die").

Example

Suppose that transaction T5, T10, T15 have time-stamps 5, 10 and 15 respectively.

If T5 requests a data item held by T10 then T5 will "wait".

If T15 requests a data item held by T10, then T15 will be killed ("die").

Wound-Wait scheme

It is a preemptive technique for deadlock prevention. It is a counterpart to the wait-die scheme. When Transaction Tn requests a data item currently held by Tk, Tn is allowed to wait only if it has a timestamp larger than that of Tk, otherwise Tk is killed (i.e. Tk is wounded by Tn).

In this scheme, 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:

  1. Timestamp(Tn) < Timestamp(Tk), then Tn forces Tk to be killed − that is Tn "wounds" Tk. Tk is restarted later with a random delay but with the same timestamp(k).

  2. Timestamp(Tn) > Timestamp(Tk), then Tn is forced to "wait" until the resource is available.

This scheme allows the younger transaction requesting a lock to "wait" if the older transaction already holds a lock, but forces the younger one to be suspended ("wound") if the older transaction requests a lock on an item already held by the younger one.

Example

Again, suppose that Transactions T5, T10, T15 have time-stamps 5, 10 and 15 respectively.

If T5 requests a data item held by T10, then data item will be preempted from T10 and T10 will be suspended. ("wounded")

If T15 requests a data item held by T10, then T15 will "wait".

Summary

In both the cases, only the transaction that enters the system at a later timestamp (i.e. the younger transaction) might be killed and restarted.

like image 160
Parth Patel Avatar answered Oct 01 '22 23:10

Parth Patel