Operating Systems

Final exam will be 6 May (thurs) 10am. The room is not yet known.

Note on Date of Midterm (vote)

The midterm will cover chapters 0-3 of the notes, i.e., linkers and tanenbaum chapters 1-3. We will finish chapter 3 in about 3 lectures and the exam must be given before the break so that it can be graded a returned by the deadline.

Thus the two natural possibilities are thurs 4 march and tues 9 mar march. The exam would be the same on either day.

The exam is closed book and closed notes. I will post sample questions next tuesday.

The vote was held and the winner was tuesday 9 March.

End of Note

Note on lab 2 (scheduling).

If several processes are waiting on I/O, you may assume noninterference. For example, assume that on cycle 100 process A flips a coin and decides its wait is 6 units (i.e., during cycles 101-106 A will be blocked. Assume B begins running at cycle 101 for a burst of 1 cycle. So during 101 process B flips a coin and decides its wait is 3 units. You do NOT alter process A. That is, Process A will become ready after cycle 106 (100+6) so enters the ready list cycle 107 and process B becomes ready after cycle 104 (101+3) and enters ready list cycle 105.

End of Note

Chapter 3: Deadlocks

A deadlock occurs when every member of a set of processes is waiting for an event that can only be caused by a member of the set.

Often the event waited for is the release of a resource.

In the automotive world deadlocks are called gridlocks.

• The processes are the cars.
• The resources are the spaces occupied by the cars

Reward: One point extra credit on the final exam for anyone who brings a real (e.g., newspaper) picture of an automotive deadlock. You must bring the clipping to the final and it must be in good condition. Hand it in with your exam paper. Note that it must really be a gridlock, i.e., motion is not possible without breaking the traffic rules. A huge traffic jam is not sufficient.

For a computer science example consider two processes A and B that each want to print a file currently on tape.

1. A has obtained ownership of the printer and will release it after printing one file.
2. B has obtained ownership of the tape drive and will release it after reading one file.
3. A tries to get ownership of the tape drive, but is told to wait for B to release it.
4. B tries to get ownership of the printer, but is told to wait for A to release the printer.

Bingo: deadlock!

3.1: Resources

The resource is the object granted to a process.

3.1.1: Preemptable and Nonpreemptable Resourses

• Resources come in two types
  1. Preemptable, meaning that the resource can be taken away from its current owner (and given back later). An example is memory.
  2. Non-preemptable, meaning that the resource cannot be taken away. An example is a printer.
• The interesting issues arise with non-preemptable resources so those are the ones we study.
• Life history of a resource is a sequence of
  1. Request
  2. Allocate
  3. Use
  4. Release
• Processes make requests, use the resourse, and release the resourse. The allocate decisions are made by the system and we will study policies used to make these decisions.

3.1.2: Resourse Acquisition

Simple example of the trouble you can get into.

• Two resources and two processes.
• Each process wants both resources.
• Use a semaphore for each. Call them S and T.
• If both processes execute P(S); P(T); --- V(T); V(S)
  all is well.
• But if one executes instead P(T); P(S); -- V(S); V(T)
  disaster! This was the printer/tape example just above.

Recall from the semaphore/critical-section treatment last chapter, that it is easy to cause trouble if a process dies or stays forever inside its critical section. Similarly, we assume that no process maintains a resource forever. It may obtain the resource an unbounded number of times (i.e. it can have a loop forever with a resource request inside), but each time it gets the resource, it must release it eventually.

3.2: Introduction to Deadlocks

To repeat: A deadlock occurs when a every member of a set of processes is waiting for an event that can only be caused by a member of the set.

Often the event waited for is the release of a resource.

3.2.1: (Necessary) Conditions for Deadlock

The following four conditions (Coffman; Havender) are necessary but not sufficient for deadlock. Repeat: They are not sufficient.

1. Mutual exclusion: A resource can be assigned to at most one process at a time (no sharing).
2. Hold and wait: A processing holding a resource is permitted to request another.
3. No preemption: A process must release its resources; they cannot be taken away.
4. Circular wait: There must be a chain of processes such that each member of the chain is waiting for a resource held by the next member of the chain.

The first three are characteristics of the system and resources. For a given system fixed set of resource they are either true or false, i.e., they don't change with time. The truth or falsehood of the last condition does indeed change with time as the resources are requested/allocated/released.

3.2.2: Deadlock Modeling

On the right is the Resource Allocation Graph, also called the Reusable Resource Graph.

• The processes are circles.
• The resources are squares.
• An arc (directed line) from a process P to a resource R signifies that process P has requested (but not yet been allocated) resource R.
• An arc from a resource R to a process P indicates that process P has been allocated resource R.

Homework: 5.

Consider two concurrent processes P1 and P2 whose programs are.

P1: request R1       P2: request R2
    request R2           request R1
    release R2           release R1
    release R1           release R2

On the board draw the resource allocation graph for various possible executions of the processes, indicating when deadlock occurs and when deadlock is no longer avoidable.

There are four strategies used for dealing with deadlocks.

1. Ignore the problem
2. Detect deadlocks and recover from them
3. Avoid deadlocks by carefully deciding when to allocate resources.
4. Prevent deadlocks by violating one of the 4 necessary conditions.

3.3: Ignoring the problem--The Ostrich Algorithm

The “put your head in the sand approach”.

• If the likelihood of a deadlock is sufficiently small and the cost of avoiding a deadlock is sufficiently high it might be better to ignore the problem. For example if each PC deadlocks once per 100 years, the one reboot may be less painful that the restrictions needed to prevent it.
• Clearly not a good philosophy for nuclear missile launchers.
• For embedded systems (e.g., missile launchers) the programs run are fixed in advance so many of the questions Tanenbaum raises (such as many processes wanting to fork at the same time) don't occur.

3.4: Detecting Deadlocks and Recovering From Them

3.4.1: Detecting Deadlocks with Single Unit Resources

Consider the case in which there is only one instance of each resource.

• Thus a request can be satisfied by only one specific resource.
  
  
• In this case the 4 necessary conditions for deadlock are also sufficient.
  
  
• Remember we are making an assumption (single unit resources) that is often invalid. For example, many systems have several printers and a request is given for “a printer” not a specific printer. Similarly, one can have many tape drives.
  
  
• So the problem comes down to finding a directed cycle in the resource allocation graph. Why?
  Answer: Because the other three conditions are either satisfied by the system we are studying or are not in which case deadlock is not a question. That is, conditions 1,2,3 are conditions on the system in general not on what is happening right now.

To find a directed cycle in a directed graph is not hard. The algorithm is in the book. The idea is simple.

1. For each node in the graph do a depth first traversal to see if the graph is a DAG (directed acyclic graph), building a list as you go down the DAG.
   
   
2. If you ever find the same node twice on your list, you have found a directed cycle, the graph is not a DAG, and deadlock exists among the processes in your current list.
   
   
3. If you never find the same node twice, the graph is a DAG and no deadlock occurs.
   
   
4. The searches are finite since the list size is bounded by the number of nodes.