“Five philosophers sit around a circular table. Each philosopher spends his life alternatively thinking and eating. In the center of the table is a large plate of spaghetti. A philosopher needs two chopsticks to eat a helping of spaghetti. Unfortunately, as philosophy is not as well paid as computing, the philosophers can only afford five chopsticks. One chopstick is placed between each pair of philosophers and they agree that each will only use the chopstick to his immediate right and left. This limitation of resource availability defines the challenges that come with today’s multi-processing operating systems designs. Deadlock occurs when at least each of two processes is holding resources that the other needs to complete its task. The same occurrence will lead to starvation if all five philosophers pick up a chopstick at the same time and none of them is willing to give up his for the other to eat. The waiting processes of the operating system will enter an infinite loop which will run up the allocated virtual memory resulting in a system freeze or crash.
Since deadlocks are caused by active conflicting processes waiting on resources to be released, the most intuitive way to resolve them is to identify and terminate the conflicting tasks. But that is easier said than done especially when the conflict has already escalated to impact the operating system as a whole. In these occurrences, a soft or hard system reboot may be the only way to get the operating system back on a working condition.
A soft reboot is the process of rebooting the operating system from its user interface. When reboot is needed, it’s usually recommended as best practice because it allows the system to auto-close all applications and to systemically restore the operating system with chances of saving the RAM. However, this option may not be available on deadlocks where all the system resources are frozen. In such cases, the last option remaining is the hard reboot that consist of physically cutting off the computer's power supply. Hard reboots will unavoidably flash the RAM and should only be used as last resort. View the potential risks of data loss and delays that deadlock issues can cause, proactively preventing their occurrences should be priority.
“Mutual Exclusion”, “Hold-and-wait” and “No preemption” are three sine qua non conditions for deadlocks. So, a user can avoid deadlocks by preventing all three conditions from occurring at the same time or at least one of the three conditions from ever occurring.
Mutual exclusion (mutex) algorithms are used in concurrent programming to avoid the simultaneous use of a common resource, such as a global variable. By preventing two processes from sharing the same resource, mutex ensures the integrity of the information received and processed by the resource in question. “Hold-and-wait” refers to the design principle where the process grabs and holds the available resources that it needs to perform a task then waits for the resources that are not yet available. Preemption is the ability of the operating system to interrupt a currently scheduled task in favor of a higher priority task. So no preemption will occur if the system does not have that ability.
The need for mutual exclusion could be avoided if the user only requests the resources that he needs when he needs them. as an example, the user should avoid printing from different programs at the same time. Closing the applications that we are not using will help alleviate the burden of “hold-and-wait”. If we must allow a program to use a resource that is already held by a different program, manually stopping, pausing or interrupting the first program before starting the second one will help address the “no preemption”. If avoiding deadlocks is a user issue, why should he pay the big bucks for newer, faster and better computers?
More than a user concern, the problem of the dining philosopher should primarily be addressed within the operating system. Let's assume each chopstick is numbered, and philosophers always have to pick up the lower numbered chopstick before the higher one. Philosopher five picks up chopstick 4, philosopher 4 picks up chopstick 3, philosopher 3 picks up chopstick 2, and philosopher 2 picks up chopstick 1. Philosopher 1 is hungry, and without this assumption, would pick up chopstick 5, thus causing deadlock. However, if the lower number rule is in effect, he/she has to pick up chopstick 1 first, and it is already in use, so he/she is blocked. Philosopher 5 picks up chopstick 5, eats, and puts both down, allows philosopher 4 to eat. Eventually everyone gets to eat. The implementation of this solution however will require to have every possible resource numbered and will also require all process to make their requests in order. An alternate solution will be to have all process request all of the resources that they need at the same time thus granting or denying all of them at once.
The solutions above though theoretically viable cannot be implemented in the real world because of the need for resource requesting system to operate on a predefined manner. Therefore, most systems today operate on the ostrich algorithm which assumes that since deadlocks are not likely to occur very frequently, the easiest and most cost effective solution is to stick your head in the sand and pretend there is no problem.