š Deadlock Detection Algorithm Usage (43 MCQs)
š From Operating System ⢠7. Deadlocks ⢠43 questions available
What is Deadlock Detection Algorithm Usage?
Definition:
The frequency and timing of detection algorithm invocation involve trade-offs between detection latency, CPU overhead, and number of affected processes.
Example:
Running detection only when CPU utilization drops below threshold reduces overhead compared to periodic execution every .
Reason:
Optimal usage policy minimizes performance impact while ensuring deadlocks are detected promptly enough to limit damage and recovery cost.
š All Deadlock Detection Algorithm Usage MCQs
Q1. What are the two primary factors determining how often to invoke the deadlock detection algorithm?
š Explanation: The text explicitly states that the invocation frequency depends on the likelihood of deadlock occurrence and the number of processes affected when it happens.
Q2. If deadlocks occur frequently, how should the detection algorithm be invoked?
š Explanation: Frequent deadlocks mean resources are often tied up idly. To minimize this waste and prevent the deadlock cycle from growing, the detection algorithm should be run frequently to resolve issues quickly.
Q3. What happens to resources allocated to deadlocked processes?
š Explanation: Processes in a deadlock are blocked and cannot proceed. Therefore, any resources they hold are unused (idle) and unavailable to other processes until the deadlock is resolved.
Q4. Why is it problematic if the number of processes in a deadlock cycle grows?
š Explanation: As more processes join the deadlock cycle, more resources become idle, reducing system throughput. Additionally, recovering from a large deadlock (e.g., terminating many processes) is more costly and disruptive than resolving a small one.
Q5. When does a deadlock typically occur in terms of resource requests?
š Explanation: Deadlocks arise when a process requests a resource that is not available and is held by another waiting process, creating a chain. The final request that cannot be granted completes the circular wait.
Q6. What is the benefit of invoking the detection algorithm every time a request cannot be granted?
š Explanation: By running detection immediately upon a failed request, the system can pinpoint the most recent request as the one that completed the cycle. This helps identify the 'triggering' process for potential recovery actions.
Q7. What is the main disadvantage of invoking the detection algorithm on every failed request?
š Explanation: Running the detection algorithm (which can be O(n²) or O(m*n²)) for every single resource request adds significant processing time to each request, slowing down overall system performance.
Q8. Which strategy is considered less expensive than checking every request?
š Explanation: Periodic checks (e.g., hourly) or trigger-based checks (e.g., low CPU usage) reduce the frequency of running the expensive detection algorithm, saving computational resources.
Q9. Why might CPU utilization drop during a deadlock?
š Explanation: Deadlocked processes are blocked, waiting for resources. They do not perform useful work, leading to lower CPU utilization as the CPU may have no ready processes to run.
Q10. If the detection algorithm is invoked at arbitrary points, what is a likely consequence regarding causality?
š Explanation: If time has passed since the deadlock formed, multiple cycles may exist, and many processes may be involved. It becomes ambiguous which specific request triggered the deadlock, making 'blame' assignment difficult.
Q11. In reality, who causes a deadlock?
š Explanation: While we often blame the last requester for simplicity, a deadlock is a circular dependency. Every process in the cycle holds a resource needed by the next, so they all jointly contribute to the deadlock condition.
Q12. Can a single resource request create multiple cycles?
š Explanation: In complex systems with many resource types and dependencies, one new request might complete several different circular chains simultaneously, creating multiple cycles in the resource graph.
Q13. What is a common metric used to trigger deadlock detection periodically?
š Explanation: A significant drop in CPU utilization often indicates that many processes are blocked (waiting), which is a symptom of deadlock. Thus, it serves as a practical trigger for detection.
Q14. If deadlocks are rare, which invocation strategy is most efficient?
š Explanation: If deadlocks are rare, the overhead of checking every request is wasted. Periodic checking balances the low risk of deadlock with the cost of detection, avoiding unnecessary computation.
Q15. What is the 'extreme' case for invoking the detection algorithm?
š Explanation: The text describes invoking the algorithm on every failed allocation request as the 'extreme' approach, offering maximum responsiveness at the cost of maximum overhead.
Q16. Why is identifying the 'causing' process useful?
š Explanation: Knowing which process triggered the deadlock can help the recovery algorithm decide which victim to select. For example, terminating the triggering process might break the cycle with minimal disruption if it was the last link added.
Q17. If the detection algorithm is run infrequently, what risk increases?
š Explanation: Infrequent detection means a deadlock can persist for longer. During this time, other processes may request resources held by the deadlocked set, potentially joining the deadlock or being blocked by it, expanding the scope of the problem.
Q18. What does the phrase 'resources allocated to deadlocked processes will be idle' imply?
š Explanation: Idle resources are those that are allocated but not being used productively because the holding process is stuck. This represents a loss of potential system capacity and efficiency.
Q19. Which statement best describes the trade-off in detection frequency?
š Explanation: Frequent detection catches deadlocks early (accurate/timely) but costs more CPU time (overhead). Infrequent detection saves CPU time but allows deadlocks to persist and grow (less timely).
Q20. If CPU utilization is high, does it mean there is no deadlock?
š Explanation: High CPU utilization suggests processes are actively executing. While a partial deadlock might exist, a total system deadlock usually results in low CPU usage. However, high CPU doesn't guarantee *no* deadlock (e.g., if non-deadlocked processes are busy).
Q21. What is the role of the 'most recent request' in deadlock identification?
š Explanation: Since the most recent request completed the cycle, it is convenient to label it as the 'cause'. This simplifies recovery logic, even though technically all parties are responsible.
Q22. Why is it difficult to identify the causing process if many cycles exist?
š Explanation: With multiple cycles, there isn't a single 'last' request that caused everything. Several requests may have completed different cycles simultaneously or in quick succession, making it hard to pinpoint a single culprit.
Q23. What is the impact of deadlock on system throughput?
š Explanation: Deadlocked processes do no useful work. If many processes are deadlocked, the amount of work completed by the system (throughput) drops significantly.
Q24. If a system has few resource types, how does this affect cycle creation?
š Explanation: With fewer resource types, the dependency graph is simpler. A single request is less likely to intersect with multiple independent waiting chains, reducing the chance of creating multiple distinct cycles at once.
Q25. What is the primary goal of tuning the detection frequency?
š Explanation: The goal is optimization. Running detection too often wastes CPU; running it too rarely wastes resources held by deadlocks. Tuning finds the sweet spot where total system cost (overhead + deadlock loss) is minimized.
Q26. Can the detection algorithm prevent deadlocks?
š Explanation: Detection is a reactive measure. It finds deadlocks that have already happened. Prevention and avoidance are proactive measures that stop deadlocks from forming.
Q27. If a request is granted immediately, is detection invoked in the 'every request' strategy?
š Explanation: The strategy specifies invocation when a request *cannot* be granted immediately. If granted, no wait occurs, so no deadlock is formed by that request, and detection is skipped to save overhead.
Q28. What does 'arbitrary points in time' refer to in the context of detection?
š Explanation: Arbitrary points imply no strict logical trigger related to system state changes (like requests) or regular intervals. It might mean random checks or checks based on loose criteria, making causality hard to trace.
Q29. Why is the 'once per hour' example given?
š Explanation: The text uses 'once per hour' as an example of a periodic strategy, contrasting it with the high-overhead 'every request' strategy. It shows a way to reduce computational cost.
Q30. If a deadlock involves 10 processes, how many resources are likely idle?
š Explanation: In a simple cycle, each process holds at least one resource. So 10 processes would hold at least 10 resources. These resources are idle because the processes are blocked. Complex cases might involve more resources per process.
Q31. What is the relationship between deadlock frequency and detection cost?
š Explanation: If deadlocks are frequent, the cost of idle resources is high. Therefore, paying the higher computational cost of frequent detection is justified to minimize resource waste.
Q32. Which factor suggests using a periodic detection strategy?
š Explanation: If deadlocks are rare, the cost of frequent detection outweighs the benefit. Periodic detection is sufficient to catch the occasional deadlock without wasting resources on constant checks.
Q33. What is the 'chain of waiting processes'?
š Explanation: A deadlock often forms a chain: P1 waits for P2, P2 waits for P3, ..., Pn waits for P1. This circular chain is the structural basis of the deadlock.
Q34. If the detection algorithm is invoked on every failed request, what can be identified?
š Explanation: Immediate invocation allows the system to correlate the current failed request with the newly formed cycle, identifying the requesting process as the one that 'completed' the deadlock.
Q35. Why is CPU utilization < 40% a good trigger?
š Explanation: A drop below a normal baseline (like 40%) suggests that processes are not running because they are waiting (blocked). This is a strong heuristic for potential deadlock.
Q36. What is the main drawback of periodic detection?
š Explanation: Between periodic checks, a deadlock can exist for minutes or hours. During this time, more processes may get stuck, and resources remain idle, increasing the negative impact.
Q37. Can a process be part of a deadlock but not be the 'causing' process?
š Explanation: Yes. In a cycle, all processes are equally responsible. The 'causing' label is often assigned to the last requester for convenience, but earlier participants are also part of the deadlock.
Q38. What is the effect of 'considerable overhead' on system performance?
š Explanation: Overhead means extra computation. If the detection algorithm runs frequently, each resource request takes longer to process, increasing latency and reducing overall system responsiveness.
Q39. If a system has high deadlock frequency, what is the likely impact on resource utilization?
š Explanation: Although resources are 'allocated', they are not doing useful work. Thus, the *effective* utilization (productive work) is low, even if the *allocation* rate is high.
Q40. Which strategy provides the best information for recovery?
š Explanation: Identifying the specific 'causing' process (possible with immediate detection) gives the recovery algorithm a better target for termination or preemption, potentially minimizing disruption.
Q41. What is the 'resource graph' mentioned in the text?
š Explanation: The resource graph refers to the graphical representation of resource allocation (RAG) or waiting (WFG), where cycles indicate deadlocks.
Q42. If multiple cycles exist, how many processes are deadlocked?
š Explanation: Any process participating in a cycle is deadlocked. If there are multiple disjoint or overlapping cycles, all unique processes involved in any of those cycles are considered deadlocked.
Q43. Why is the 'extreme' strategy rarely used in practice?
š Explanation: For systems with thousands of requests per second, running a complex detection algorithm for every failed request would consume too much CPU, degrading performance for all users.