Deadlock Recovery Technique in Operating System

Suppose, a deadlock detection algorithm has detected a deadlock. What's next? Some way is needed to recover and get the system going again. There are various ways of recovering from deadlock, however, none of them are attractive.

Recovery through Pre-emption 

In some cases, it may be possible to temporarily take a resource away from its current process and give it to another process. In many cases, manual intervention may be required, especially in batch-processing operating systems running on mainframes. 

Taking a resource away from a process for allocating it to another process, and then returning the resource back is highly dependent on the nature of the resource. Recovering this way is frequently difficult or impossible. Choosing the process to suspend depends largely on which ones have resources that can easily be taken back.

Recovery through Rollback

If the system designers and machine operators know that deadlocks are likely, they can arrange to have processes checkpointed periodically. Checkpointing a process means that its state is written to a file so that it can be restarted later. The checkpoint contains not only the memory image but also the resource state, that is, which resources are currently assigned to the process. To be most effective, new checkpoints should not overwrite old ones but should be written to new files, so as the process executes, a whole sequence of checkpoint files is accumulated.

When a deadlock is detected, it is easy to see which resources are needed. To do the recovery, a process that owns a needed resource is rolled back to a point in time before it acquired some other resource by starting one of its earlier checkpoints. 

Recovery through Killing Processes

The crudest, but simplest way to break a deadlock is to kill one or more processes. One possibility is to kill a process in the cycle. With a little luck, the other processes will be able to continue. If this does not help, it can be repeated until the cycle is broken.

Alternatively, a process not in the cycle can be chosen as the victim in order to release its resources. In this approach, the process to be killed is carefully chosen because it is holding resources that some process in the cycle needs.

Where possible, it is best to kill a process that can be rerun from the beginning with no ill effects.

On the other hand, a process that updates a database cannot always be run a second time safely.

Happy Exploring!