• Allow system to enter deadlock state
• Detection algorithm
• Recovery scheme

Recovery from Deadlock: Process Termination

• Abort all deadlocked processes.
• Abort one process at a time until the deadlock cycle is eliminated.
• In which order should we choose to abort?l Priority of the process.
• How long process has computed, and how much longer to completion.
• Resources the process has used.l Resources process needs to complete.l How many processes will need to be terminated.
• Is process interactive or batch?

Recovery from Deadlock: Resource Preemption

• Selecting a victim – minimize cost.
• Rollback – return to some safe state, restart process for that state.
• Starvation – same process may always be picked as victim, include number of rollback in cost factor.

• Mutual Exclusion – not required for sharable resources; must hold for nonsharable resources.
• Hold and Wait – must guarantee that whenever a process requests a resource, it does not hold any other resources.
• Require process to request and be allocated all its resources before it begins execution, or allow process to request resources only when the process has none.
• Low resource utilization; starvation possible.Restrain the ways request can be made.
• No Preemption :
• If a process that is holding some resources requests another resource that cannot be immediately allocated to it, then all resources currently being held are released.
• Preempted resources are added to the list of resources for whichthe process is waiting.
• Process will be restarted only when it can regain its old resourcesas well as the new ones that it is requesting.
• Circular Wait – impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

• Ensure that the system will never enter a deadlock state.
• Allow the system to enter a deadlock state and then recover.
• gnore the problem and pretend that deadlocks never occur in he system; used by most operating systems, including UNIX.

• Mutual exclusion: only one process at a time can use aresource.
• Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes.
• No preemption: a resource can be released only voluntarily by the process holding it, after that process has completed its task.
• Circular wait: there exists a set {P0, P1, …, P0} of waitingprocesses such that P0 is waiting for a resource that is held by P1, P1 is waiting for a resource that is held by P2, …, Pn–1 is waiting for a resource that is held by Pn, and P0 is waiting for a resource that is held by P0.Deadlock can arise if four conditions hold simultaneously.

• Across platforms, thread scheduling1 tends to be based on at least the following criteria:
  a priority, or in fact usually multiple "priority" settings that we'll discuss below;
• a quantum, or number of allocated timeslices of CPU, which essentially determines the amount of CPU time a thread is allotted before it is forced to yield the CPU to another thread of the same or lower priority (the system will keep track of the remaining quantum at any given time, plus its default quantum, which could depend on thread type and/or system configuration);
• a state, notably "runnable" vs "waiting";
• metrics about the behaviour of threads, such as recent CPU usage or the time since it last ran (i.e. had a share of CPU), or the fact that it has "just received an event it was waiting for".
  

Most systems use what we might dub priority-based round-robin scheduling to someextent. The general principles are:

• a thread of higher priority (which is a function of base and local priorities) will preempt a thread of lower priority;
• otherwise, threads of equal priority will essentially take turns at getting an allocated slice or quantum of CPU;
• there are a few extra "tweaks" to make things work