0
$\begingroup$

I know deadlock occurs when Process A has resource R1 and is waiting for resource R2, while process B has resource R2 and is waiting for resource R1, however why don't both processes just let go of the resource they are currently owning before/while waiting for the other resource? How does A keep holding on to R1 even though it is waiting for R2.

$\endgroup$

3 Answers 3

3
$\begingroup$

To answer part of your question: Processes are not smart. Processes just execute the code of their program, so if the program of P1 has not been written to release R1 when it's done with it, it won't be released.

Besides, the classical setting in which a deadlock happens does not have to do with processes not releasing resources after they are done with them, but rather with competing processes trying to acquire the needed resources.

Process A needs both R1 and R2 to perform some task, so it starts acquiring them. It acquires R1, and tries to acquire R2.

Just before P1 gets to acquire R1, some process P2 that also needs both R1 and R2 tries to acquire them. This time P2 starts with acquiring R2, and succeeds.

At this point the following two things happen:

  • P1 tries to acquire R2 which is unavailable, so it waits for R2 be released.
  • P2 tries to acquire R1 which is unavailable, so it waits for R1 be released.

From this point on both P1 and P2 are stuck waiting for another resource that will never be released, i.e., they are in a deadlock.

Notice that no process ever held a lock on a resource that didn't intend to use. The problem was that P1 and P2 tried to lock the resources in a different order.

Finally, you might think that when P1 tries to acquire R2, and finds that it is unavailable it could just temporarily release R1 and try to acquire both R1 and R2 at a later time. However, without additional synchronization, this also doesn't ensure that P1 and P2 will manage to acquire the needed resources. The following could happen:

  • P1 acquires R1, P2 acquires R2.
  • P1 tries to acquire R2, and finds that R2 is unavailable.
  • P2 tries to acquire R1, and finds that R1 is unavailable.
  • P1 releases R1.
  • P2 releases R2.
  • P1 acquires R1 and is about to acquire R2.
  • P2 acquires R2 and is about to acquire R1.
  • P1 tries to acquire R2, and finds that R2 is unavailable.
  • P2 tries to acquire R1, and finds that R1 is unavailable.
  • ....
$\endgroup$
2
  • $\begingroup$ Thank you so much! $\endgroup$ May 15, 2021 at 15:45
  • 1
    $\begingroup$ Note that the "release R2 if R1 isn't immediately available" is not always feasible. Think modifying R2 in some way, and then refering to R1 to guide further changes to both. Releasing half-modified R2 is just wrong. $\endgroup$
    – vonbrand
    May 15, 2021 at 19:15
0
$\begingroup$

You run into a problem when thread A has aquired lock 1, and then decides that it needs both lock 1 and lock 2, and tries to aquire lock 2, while thread B has aquired lock 2, and then decides that it needs both lock 2 and lock 1.

Once a thread starts aquiring a lock, that operation can't be stopped - it hangs until the lock is available.

$\endgroup$
0
$\begingroup$

There are four necessary conditions for deadlock , and these are

1. Mutual Exclusion

2. Hold and Wait

3. No preemption

4. Circular wait

And to prevent deadlock we need to disable one of these four necessary conditions.Now the solution to no preemption is taking resources away ( which requires hardware support ). But this will cause inconsistency e.g., if a process P is using printer and now another process Q demands for it. And now if printer is given to Q , then for P we need to start the task again.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.