--- title: "Approaches to avoid distributed deadlock" subject: "Distributed System" chapter: 8 key: "semester_7/distributed_system:deadlock-avoidance-approaches" source: https://www.bctengineer.com/q/semester_7/distributed_system/deadlock-avoidance-approaches site: BCT Engineering --- # Approaches to avoid distributed deadlock Distributed System · Chapter 8: Transaction and Concurrency Control - Asked in: 2076 Chaitra, 4+4 marks - Video: [Deadlock Prevention :DBMS](https://www.youtube.com/watch?v=WZtebOyiu0M) — Shrenik Jain - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/deadlock-avoidance-approaches - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-8 ## Question What are the alternative approaches to avoid possibility of deadlock in distributed system? Explain. ## Short answer Deadlock can be avoided by acquiring all locks at start, enforcing a global resource ordering to prevent cyclic waits, using lock timeouts, or applying timestamp-based schemes: wait-die aborts younger requesters, wound-wait preempts younger holders, so waits only flow from younger to older, preventing cycles. Optimistic or timestamp ordering concurrency control also avoids locks entirely. ## Answer A deadlock happens when transactions wait for each other's locks in a cycle. It can be prevented by breaking one of its necessary conditions (mutual exclusion, hold and wait, no pre-emption, circular wait). The alternative approaches are: 1. **Lock all objects at the start (no hold and wait)**: a transaction acquires all its locks at the start in one atomic step. It is simple but wastes concurrency, and the required objects are often not known in advance. 2. **Ordering of resources (no circular wait)**: lock objects in a fixed global order. A transaction cannot request an earlier object while holding a later one. This is hard to apply across many servers. 3. **Timeouts**: a lock is valid for a limited time. After the time limit, the lock is *vulnerable*; if another transaction wants it, the holder is aborted. Easy, but it aborts transactions that were only slow, and the timeout value is hard to choose. 4. **Timestamp-based prevention** (each transaction has a unique timestamp, older = smaller): - **Wait-die** (non-pre-emptive): if the requester is older than the holder, it waits; if younger, it dies (aborts and restarts with the same timestamp). - **Wound-wait** (pre-emptive): if the requester is older, it wounds (aborts) the holder; if younger, it waits. In both, waiting goes in only one direction (by age), so no cycle can form, and there is no starvation because a restarted transaction keeps its original timestamp. 5. **Optimistic or timestamp ordering concurrency control**: no locks, so no deadlock. If avoidance is too restrictive, detection and recovery (wait-for graph, edge chasing, abort a victim) are used instead. ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. In wait-die, what happens if the requester is younger than the lock holder? A. It waits B. It dies (aborts and restarts with the same timestamp) C. It wounds the holder D. It gets the lock Answer: B. Older requesters wait; younger ones die. (Key point: Wait-die) 2. In wound-wait, what happens if the requester is older than the holder? A. The requester waits B. The requester wounds (aborts) the holder C. The requester dies D. Both abort Answer: B. Wound-wait is pre-emptive: an older requester aborts the younger holder. (Key point: Wound-wait) 3. Why do wait-die and wound-wait avoid starvation? A. Restarted transactions keep their original timestamp B. Locks never expire C. Transactions are never aborted D. New timestamps are always smaller Answer: A. A restarted transaction keeps growing relatively older, so it eventually wins. (Key point: Why no starvation) 4. Which condition does locking objects in a fixed global order break? A. Mutual exclusion B. Circular wait C. No pre-emption D. Hold and wait Answer: B. With a global order no cycle of waiting can form. (Key point: Ordered locking) ## Related in Distributed System - [Distributed deadlock and recovery](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-deadlock-note) — Distributed System, chapter 8, asked 3× - [Distributed deadlock; two-phase commit](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adistributed-deadlock-2pc) — Distributed System, chapter 8 - [Lock; distributed CC; deadlock situation](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Alock-cc-deadlock-situation) — Distributed System, chapter 8 - [Autonomous vs distributed system](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Aautonomous-vs-distributed) — Distributed System, chapter 1 - [Models of distributed system](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Amodels-of-ds) — Distributed System, chapter 1 - [True distributed system; middleware organisation](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Atrue-ds-middleware) — Distributed System, chapter 3 ## Related in other subjects - [Distributed system in big data example](https://www.bctengineer.com/question.md?key=semester_8%2Fbig_data_technologies%3Adistributed-system-example) — Big Data Technologies, chapter 1 - [Short note: Distributed system implementation](https://www.bctengineer.com/question.md?key=semester_6%2Fobject_oriented_analysis_and_design%3Ashort-note-distributed-implementation-issues) — Object Oriented Analysis and Design, chapter 4 - [Distributed system and Hadoop](https://www.bctengineer.com/question.md?key=semester_8%2Finformation_system%3Adistributed-system-hadoop-voluminous-data) — Information System, chapter 8 - [Race condition; critical section approaches](https://www.bctengineer.com/question.md?key=semester_6%2Foperating_system%3Arace-condition-critical-section-approaches) — Operating System, chapter 3