Resource-Allocation Graph

• Process

• Resource Type w/ 4 instances

• Pi requests instance of Rj

• Pi is holding an instance of Rj

QUESTION:

• How would you know if there's a DEADLOCK based on the resource allocation graph?

ANSWER:
If graph contains no cycles => no deadlock.
If graph contains a cycle

• if only one instance per resource type, then deadlock (meaning if the cycle goes on a single path, it will result to a DEALOCK).

• if several instances per resource type, possibility of deadlock (meaning if the resource allocation graph has several cycles it has a POSSIBILITY for DEADLOCK).

Unsafe State in Resource-Allocation Graph

· The RAG above is compose of 2 resources and 2 processes
· P1 holds an instance of R1
· P2 is requesting an instance of R1
· P2 holds an instance of R2
· P1 may request an instance of R2

Resource-Allocation Graph For Deadlock Avoidance

· The Resource Allocation Graph (RAG) above is composed of 2 processes and 2 resources.
· P1 holds an instance of R1
· P2 requests an instance of R1
· P1 and P2 may request an instance of R2

Resource-Allocation Graph With A Cycle But No Deadlock

• P1 is holding an instance of R2 and requests instance of R1.
• P2 is holding an instance of of R1.
• P3 is holding an instance of R1 and requests instance of R2.
• P4 is holding instance of R2.

Resource-Allocation Graph With A Deadlock

• P1 is holding an instance of R2 and requests instance of R2 and requests instance of R1
• P2 is holding an instance of R1 and R2 then requests of instance of R3
• P3 is holding an instance of R3 and requests an instance of R2
• R1 or resource 1 is composed of only one instance
• R2 has 2 instances
  
• R3 has one instance
  
• R4 has 3 instances

Example of Resource-Allocation Graph

• P1 is holding an instance of R2 and requests instance of R1.
  
• P2 is holdng an instsnce of R1 and R2 ang requests of instance of R3.
  
• P3 is holding an instance of R3.

Recovery or Deadlock Recovery

• Abort all deadlock processes and release resource - too drastic - will lead to loss of work
• Abort one process at a time - releasing resources until no deadlock
  How do we determine which process to abort first ? - priority ordering, process which has done least work
• Selectively restart processes from a previous checkpoint i.e. before it claimed any resources
  difficult to achieve - sometimes impossible
• Successively withdraw resources from a process and give to another process until deadlock is broken. How to choose which processes and which resources ?

1. Complex decisions due to the large number of processes present within a system
2. Difficult to automate
3. Use Operator to resolve conflicts - BUT this requires the operator to have skill and understanding of what processes are actually doing

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?

 - Priority of the process.

 - How long process has computed, and how much longer to completion.

 - Resources the process has used.

 - Resources process needs to complete.

 - How many processes will need to be terminated.

 - Is process interactive or batch?

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.

Deadlock Detection

In Operating Systems a special resource-allocation graph algorithm can be used to detect whether there is any deadlock in the system. A resource-allocation graph is a directed graph consisting of two different types of nodes P = P₁, P₂,..., P_n, the set consisting of all active processes in the system, and R = R₁, R₂,..., R_m, the set consisting of all resource types in the system.

A directed edge from process P_i to resource R_j is denoted by P_i R_j and means that process P_i requested an instance resource type R_j, and is currently waiting for that resource. A directed edge from resource type R_j to process P_i, is denoted by R_j P_i and means that an instance of resource type R_j has been allocated to process P_i.

The following figure illustrates a resource-allocation graph where processes are denoted by circles and resources by squares. Notice that if there is a circular wait among the processes, then it implies that a deadlock has occurred.

Given a resource allocation graph in which each resource type has exactly one instance, your job is to determine whether there is a deadlock in the system. In case a deadlock exists, you must also show the sequence of processes and resources involved.

Input

The input begins with a single positive integer on a line by itself indicating the number of the cases following, each of them as described below. This line is followed by a blank line, and there is also a blank line between two consecutive inputs.

We will assume that processes are named by capital letters and resources by small letters, so we limit to 26 the number of processes and/or resources. Therefore, the first line of input consists of three numbers N, M and E, respectively, the number of processes, the number of resources and the number of edges. The edges are given in the following lines as pairs of letters linked by a `-' character. Edges are separated by spaces or newlines.

Output

For each test case, the output must follow the description below. The outputs of two consecutive cases will be separated by a blank line.

The output must be `NO' if no deadlock is detected. In case a deadlock is detected, the output must be `YES' followed by the sequence or sequences of circular waits detected, one per line. If more then one sequence is found, they should all be output in increasing order of their length.

Sample Input

1

2 2 4
A-b B-a
a-A b-B

Sample Output

YES
A-b-B-a-A

Deadlock Prevention

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 which the process is waiting.
  
• Process will be restarted only when it can regain its old resources, as 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.

Circular Wait – impose a total ordering of all resource types, and require that each process requests resources in an increasing order of enumeration.

Deadlock prevention - low device utilization and reduced system throughput.
Deadlock avoidance

• Given the complete sequence of requests and releases for each process, we can decide for each request whether or not the process should wait.
  
• For every request, the system
  tconsiders the resources currently available, the resources currently allocated, and the future requests and releases of each process, and
  decides whether the current request can be satisfied or must wait to avoid a possible future deadlock.

1. 
   considers the resources currently available, the resources currently allocated, and the future requests and releases of each process, and
2. 
   decides whether the current avoid a possible future deadlock.
   
   
   
   

Methods for handling Deadlocks

Deadlock Prevention.

• Disallow one of the four necessary conditions for deadlock.

Deadlock Avoidance.

• Do not grant a resource request if this allocation have the potential to lead to a deadlock.

Deadlock Detection.

• Always grant resource request when possible. Periodically check for deadlocks. If a deadlock exists, recover from it.

Ignore the problem...

• Makes sense if the likelihood is very low.

Deadlock Characterization


• All four conditions must existsimultaneously for deadlock to occur.
• If we can prevent any one of theconditions, we prevent deadlock

1. Mutual exclusion: only one process at a time can use a resource.

2. Hold and wait: a process holding at least one resource is waiting to acquire additional resources held by other processes.

3. No preemption: a resource can be released only voluntarily by the process holding it, after that process has Completed its task.

4. Circular wait: there exists a set {P0, P1, …, P0} of waiting processes 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 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

Multiprocessor Scheduling

In computer science, multiprocessor scheduling is an NP-Complete optimization problem. The problem statement is: "Given a set J of jobs where job j_i has length l_i and a number of processors m_i, what is the minimum possible time required to schedule all jobs in J on m processors such that none overlap?" The applications of this problem are numerous, but are, as suggested by the name of the problem, most strongly associated with the scheduling of computational tasks in a multiprocessor environment.

• Will consider only shared memory multiprocessor

Real Time Scheduling

A multitasking operating system intended for real-time applications. Such applications include embedded systems (programmable thermostats, household appliance controllers), industrial robots, spacecraft, industrial control (see SCADA), and scientific research equipment.
A RTOS facilitates the creation of a real-time system, but does not guarantee the final result will be real-time; this requires correct development of the software. An RTOS does not necessarily have high throughput; rather, an RTOS provides facilities which, if used properly, guarantee deadlines can be met generally or deterministically (known as soft or hard real-time, respectively). An RTOS will typically use specialized scheduling algorithms in order to provide the real-time developer with the tools necessary to produce deterministic behavior in the final system. An RTOS is valued more for how quickly and/or predictably it can respond to a particular event than for the amount of work it can perform over a given period of time. Key factors in an RTOS are therefore a minimal interrupt latency and a minimal thread switching latency.
An early example of a large-scale real-time operating system was Transaction Processing Facility developed by American Airlines and IBM for the Sabre Airline Reservations System.

Real-Time Review

• Real time is not just “real fast”
  Real time means that correctness of result depends on both functional correctness and time that the result is delivered
  
• Soft real time
  Utility degrades with distance from deadline
  
• Hard real time
  System fails if deadline window is missed
  
• Firm real time
  Result has no utility outside deadline window, but system can withstand a few missed results

Type of Real-Time Scheduling

• Dynamic vs. Static
  Dynamic schedule computed at run-time based on tasks really executing
  Static schedule done at compile time for all possible tasks
  
• Preemptive permits one task to preempt another one of lower priority
  

• Thread Scheduling

The thread of a parent process forks a child process. The child process inherits the scheduling policy and priority of the parent process. As with the parent thread, it is the child thread whose scheduling policy and priority will be used.

The following figure illustates the flow of creation.

Figure 1-35 Inheritance of Scheduling policy and priority

• Each thread in a process is independently scheduled.
  
• Each thread contains its own scheduling policy and priority
  
• Thread scheduling policies and priorities may be assigned before a thread is created (in the threads attributes object) or set dynamically while a thread is running.
  
• Each thread may be bound directly to a CPU.
  
• Each thread may be suspended (and later resumed) by any thread within the process.

The following scheduling attributes may be set in the threads attribute object. The newly created thread will contain these scheduling attributes:

• contentionscope
  PTHREAD_SCOPE_SYSTEM specifies a bound (1 x 1, kernel-spacel) thread. When a bound thread is created, both a user thread and a kernel-scheduled entity are created.
  PTHREAD_SCOPE_PROCESS will specify an unbound (M x N, combination user- and kernel-space) thread. (Note, HP-UX release 10.30 does not support unbound threads.)
  
• inheritsched
  PTHREAD_INHERIT_SCHED specifies that the created thread will inherit its scheduling values from the creating thread, instead of from the threads attribute object.
  PTHREAD_EXPLICIT_SCHED specifies that the created thread will get its scheduling values from the threads attribute object.
  
• schedpolicy
  The scheduling policy of the newly created thread
  
• schedparam
  The scheduling parameter (priority) of the newly created thread.

Different CPU Scheduling Algorithms

• Treats ready queue as FIFO.

• Simple, but typically long/varying waiting time.

Shortest Job First (SJF)

• Give CPU to the process with the shortest next burst

• If equal, use FCFS

• Better name: shortest next cpu burst first

Round-Robin (RR)

• FCFS with Preemption

• Time quantum (or time slice)

• Ready Queue treated as circular queue

Shortest Remaining Time (SRT)

• Preemptive version of shortest process next policy

• Must estimate processing time