Deadlocks Practice Questions

Statements (I), (II), and (IV) are true. Statement (III) is false because an unsafe state does not necessarily lead to deadlock; it means that there is the potential for deadlock, but deadlock may or may not occur depending on the actual future allocation pattern.

Simulating the execution shows that by time t=4, the system enters an unsafe state leading to deadlock. At t=4, P1 holds R2=2, R3=1; P2 holds R3=1, R4=1, R1=1; P3 holds R1=2. P1 needs R1=2 but only 0 available; P2 needs no more; P3 needs R2=1 and R3=1 but none are available (P1 holds R2, P1 and P2 hold R3). With no process able to proceed and no preemption, all three are deadlocked [citation:1].

These are the four Coffman conditions. All must hold simultaneously for a deadlock to occur.

Deadlock detection does not require processes to declare their maximum resource needs in advance, unlike deadlock avoidance (Banker's algorithm). However, detection may have higher overhead for periodic checks and does not prevent deadlock; it only deals with it after it occurs.

No preemption is required for deadlock; preemption prevents it.

When P1 finishes, it releases all resources it had allocated. The new available vector equals (old available + allocation of P1). Since P1 was the first process in the safe sequence, its allocation must be less than or equal to the initial available. The available after P1 equals the sum of the initial available and its allocation. The correct answer is (5,3,2).

Option B prevents circular wait. By standardizing the lock acquisition order (e.g., always acquire 'a' before 'c' when both are needed), it ensures that no cycle of processes waiting for each other's held resources can form. The other options allow scenarios where each process holds one resource while waiting for another held by a different process, creating a deadlock cycle [citation:8].

Statement 1 is FALSE (mutual exclusion IS a necessary condition). Statement 2 is TRUE (requesting all resources at once breaks the hold and wait condition). Statement 3 is FALSE (with multi-instance resources, a cycle is necessary but not sufficient). Statement 4 is FALSE (recovery can involve process termination or resource preemption, not necessarily all processes).

Total resources = Allocation sum + Available. Allocation sum = (0+2+1, 0+1+0, 1+0+0) = (3,1,1). Available = (0,2,1) as given. So total = (3,3,2).

A safe state guarantees that there exists at least one ordering (safe sequence) in which all processes can finish without deadlock.

The Hold and Wait condition requires that a process holds at least one resource while waiting for additional resources. By forcing a process to release all resources before making a new request, this condition is eliminated, thereby preventing deadlock.

All four policies break one of the necessary conditions for deadlock. Policy I breaks 'Hold and Wait' by forcing either all resources or none. Policies II, III, and IV break 'Circular Wait' by enforcing a strict ordering of resource acquisition, making a circular chain impossible [citation:2][citation:9].

By requiring a process to request all resources before it starts execution, the process cannot hold any resource while waiting for others. This breaks the Hold and Wait condition, one of the four necessary conditions for deadlock.

The Ostrich Algorithm is simply ignoring the problem of deadlock, assuming it never happens. If a deadlock does occur, the system is rebooted. The name comes from the metaphor that an ostrich hides its head in the sand when it sees danger.

To break the 'No Preemption' condition, a process that is denied a resource request must release all the resources it currently holds. These resources are then preempted and can be allocated to the waiting process, effectively allowing preemption of resources.

Starvation occurs when a process is ready to execute but is continuously denied CPU time because the scheduler always selects other processes. This can happen in priority scheduling if a low-priority process is continually preempted by higher-priority processes.

First, compute Need = Max - Allocation: Need matrix: P0 (8,4,2), P1 (3,0,0), P2 (1,2,2). Available = (3,2,2). For REQ1 (P0 requests (0,0,2)): Check if Request ≤ Need for P0: (0,0,2) ≤ (8,4,2) yes. Check if Request ≤ Available: (0,0,2) ≤ (3,2,2) yes. Assume allocation, new Available = (3,2,0). With this allocation, no safe sequence exists because P2 cannot be satisfied. So REQ1 cannot be granted. For REQ2 (P1 requests (2,0,0)): Check if Request ≤ Need for P1: (2,0,0) ≤ (3,0,0) yes. Check if Request ≤ Available: (2,0,0) ≤ (3,2,2) yes. Assuming allocation, new Available = (1,2,2). The safe sequence P1→P0→P2 works. So only REQ2 can be granted. [Source: GATE CSE 2014 Set 1, Question 31]

With 4 resources and 3 processes each requiring a maximum of 2 resources, the worst-case allocation is 1 resource per process (total 3), leaving 1 resource available. No process can be blocked indefinitely because the available resource can always break deadlock. According to the resource allocation rule, if total resources < sum of (maximum need - 1) then deadlock cannot occur. Here, 4 < (2-1)+(2-1)+(2-1) = 3? Actually 4 >= 3, so deadlock may occur. Let's recalc: Max need =2 each. The condition for deadlock is when every process holds 1 and requests 1 more each. With 3 processes holding 1 each, 3 allocated, 1 available. One process can get the available resource. So deadlock may not occur. But the correct answer from GATE is 'Deadlock may occur'.

In a deadlock, processes are blocked waiting for resources and cannot change their state. In livelock, processes are not blocked; they continuously change their state (e.g., releasing and requesting resources) but still make no progress toward completion.

The RAG shows a cycle (P1→R2→P2→R3→P3→R1→P1). However, because resources R1 and R3 have multiple instances, a cycle is not sufficient to guarantee deadlock. The actual deadlock status depends on the available instances of R1 and R3. If one additional instance of R1 is available, P3's request could be granted, breaking the deadlock.