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

DatabaseDeadlockDatabase Deadlocks

Database Problem Overview


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.

Database Solutions


Solution 1 - Database

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.

Solution 2 - Database

Parth has given a detailed answer. Here I summarize it in a different way.

Assume that Tn requests a lock held by Tk. The following table summarizes the actions taken for wait-die and wound-wait scheme:

                           wait-die         wound-wait
Tn is younger than Tk      Tn dies          Tn waits
Tn is older than Tk        Tn waits         Tk aborts
      

Both schemes prefer older transactions with an older timestamp.

Solution 3 - Database

wait-die: When an older transaction tries to lock a DB element that has been locked by a younger transaction, it waits. When a younger transaction tries to lock a DB element that has been locked by an older transaction, it dies.

wound-wait: When an older transaction tries to lock a DB element that has been locked by a younger transaction, it wounds the younger transaction. When a younger transaction tries to lock a DB element that has been locked by an older transaction, it waits.


References:

Solution 4 - Database

The best way to understand two related topics can be achieved by comparison. So, Similarity between wait-die and wound-wait:

  1. The older transaction will "win" over the newer transaction.
  2. When transactions restart, they keep their timestamps.
  3. Eventually, the aborted (younger) transactions will become the oldest transactions in the system.

Difference between wait-die and wound wait:

  1. In wait-die, The newer transactions are killed when the newer transaction makes a request for a lock being held by an older transactions.
  2. In wound-wait, The newer transactions are killed when an older transaction makes a request for a lock being held by the newer transactions.

Solution 5 - Database

I'll put the @JingguoYao's summary a bit differently. I just rearranged it because for me (and others like me) it reads easier like this.

Assume that Tn requests a lock held by Tk. The following table summarizes the actions taken for wait-die and wound-wait scheme:

                Tn is older than Tk     Tn is younger than Tk
wait-die        Tn waits                Tn dies
wound-wait      Tk aborts               Tn waits

Both schemes prefer older transactions with an older timestamp.

Solution 6 - Database

Deadlock prevention

  • A deadlock is created when both edges form, as shown in the graph above. A young transaction requests a lock from an old transaction, and an old transaction requests a lock from a young transaction.
  • Each of the 2 techniques just prevents one of the edges from being formed while allowing the other edge, hence preemptively preventing a cycle from being formed.
  • If you notice, in both strategies, the young transaction gets aborted. Only the initiator of the lock request differs. Aborted transactions are restarted at a later point in time.

Solution 7 - Database

In both cases Old is always champ i.e. will survive. Difference is from younger transaction point of view.

If younger one is requesting a resource held by a old trans. , in wait/die he can wait to give respect as Old trans.If younger one is requesting a resource held by a old trans., in wound/die he will be force to rollback as Old trans.

In both scheme old is never in loss.

Refer:https://www.tutorialspoint.com/dbms/dbms_deadlock.htm

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionNadeem BhatiView Question on Stackoverflow
Solution 1 - DatabaseParth PatelView Answer on Stackoverflow
Solution 2 - DatabaseJingguo YaoView Answer on Stackoverflow
Solution 3 - DatabaseJason LawView Answer on Stackoverflow
Solution 4 - DatabasetechPirate99View Answer on Stackoverflow
Solution 5 - Database18446744073709551615View Answer on Stackoverflow
Solution 6 - DatabasePranaya TomarView Answer on Stackoverflow
Solution 7 - DatabaseVijnana YogiView Answer on Stackoverflow