A system has three processes in a circular wait, each holding one resource and waiting for one held by the next. A developer proposes imposing a total ordering on resource types — all processes must acquire resources in increasing order of their ID. Which Coffman condition does this eliminate, and is this alone sufficient to prevent deadlock?
AIt eliminates mutual exclusion — and yes, this alone prevents deadlock
BIt eliminates circular wait — and yes, eliminating any single Coffman condition is sufficient to prevent deadlock
CIt eliminates hold-and-wait — and yes, this alone prevents deadlock
DIt reduces circular wait — but all four conditions must be eliminated to guarantee deadlock prevention
If all processes acquire resources in the same total order, a circular chain cannot form — the process holding resource N can only be waiting for resource M where M > N, so you can never have A waiting for B while B waits for A. Crucially, all four Coffman conditions must hold simultaneously for deadlock to occur, so eliminating any one of them is sufficient. The common misconception is that you must address all four.
Question 2 Multiple Choice
A Resource-Allocation Graph for a system shows a cycle involving three processes and three resource types. What can be definitively concluded?
AThe system is currently in deadlock
BDeadlock is possible but not certain — a cycle is sufficient for deadlock only when all resource types involved have single instances
CDeadlock is present when resource types have multiple instances, but not when they have single instances
DThe system will enter deadlock within the next scheduling cycle
For single-instance resources, a cycle in the RAG is both necessary and sufficient for deadlock. For multi-instance resources, a cycle is necessary but not sufficient — the cycle might resolve if one thread finishes and releases an instance, allowing another thread in the cycle to proceed. Seeing a cycle alone does not confirm deadlock unless you know all involved resources are single-instance.
Question 3 True / False
Eliminating mutual exclusion is the most practical Coffman condition to target when designing real systems to prevent deadlock.
TTrue
FFalse
Answer: False
Mutual exclusion is often non-negotiable — mutexes are inherently non-shareable; that is their purpose. Real systems most commonly attack circular wait (by total resource ordering) or hold-and-wait (by atomic allocation). Eliminating mutual exclusion would mean allowing shared access to inherently exclusive resources, which defeats the purpose of locks entirely.
Question 4 True / False
A cycle in the Resource-Allocation Graph is a necessary condition for deadlock when all resource types involved have exactly one instance.
TTrue
FFalse
Answer: True
For single-instance resource types, a cycle in the RAG is both necessary AND sufficient for deadlock. Every process in the cycle is waiting for a resource held by the next process. With only one instance per resource type, no release can happen unless someone completes — but they cannot complete because they are waiting. The cycle is the deadlock.
Question 5 Short Answer
Why is circular wait considered the most practical Coffman condition to eliminate in system design, compared to the other three?
Think about your answer, then reveal below.
Model answer: Circular wait can be eliminated structurally without sacrificing the properties that make the other conditions necessary. Mutual exclusion is required for correct synchronization. No-preemption is often unavoidable since forcibly taking resources can leave data in inconsistent states. Hold-and-wait elimination requires atomic allocation, which can cause starvation. But imposing a total ordering on resource acquisition — all processes request resources in the same global order — prevents circular chains without adding significant overhead or compromising resource safety.
The key insight is that deadlock prevention strategies have tradeoffs. Circular wait is the most surgically targetable condition because imposing an ordering constraint is a design rule, not a change to the underlying resource model. The other conditions are often load-bearing properties of the system that cannot be removed without causing different problems.