Operating Systems

Lab #2 will be officially assigned on tuesday. It has been posted on the web page and email has been be sent to the mailing list.

2.3.6: Mutexes

My Terminology

	Busy wait	block/switch
critical	(binary) semaphore	(binary) semaphore
semi-critical	counting semaphore	counting semaphore

Tanenbaum's Terminology

	Busy wait	block/switch
critical	enter/leave region	mutex
semi-critical	no name	semaphore

2.3.7: Monitors

2.3..8: Message Passing

2.4: Classical IPC Problems

2.4.1: The Dining Philosophers Problem

A classical problem from Dijkstra

• 5 philosophers sitting at a round table
• Each has a plate of spaghetti
• There is a fork between each two
• Need two forks to eat

• The obvious solution (pick up right; pick up left) deadlocks.
• Big lock around everything serializes.
• Good code in the book.

The purpose of mentioning the Dining Philosophers problem without giving the solution is to give a feel of what coordination problems are like. The book gives others as well. We are skipping these (again this material would be covered in a sequel course). If you are interested look, for example, here.

Homework: 31 and 32 (these have short answers but are not easy). Note that the problem refers to fig. 2-20, which is incorrect. It should be fig 2-33.

2.4.2: The Readers and Writers Problem

• Two classes of processes.
  • Readers, which can work concurrently.
  • Writers, which need exclusive access.
• Must prevent 2 writers from being concurrent.
• Must prevent a reader and a writer from being concurrent.
• Must permit readers to be concurrent when no writer is active.
• Perhaps want fairness (e.g., freedom from starvation).
• Variants
  1. Writer-priority readers/writers.
  2. Reader-priority readers/writers.

Quite useful in multiprocessor operating systems and database systems. The “easy way out” is to treat all processes as writers in which case the problem reduces to mutual exclusion (P and V). The disadvantage of the easy way out is that you give up reader concurrency. Again for more information see the web page referenced above.

2.4.3: The Sleeping Barber Problem

2.4A: Summary of 2.3 and 2.4

We then defined (binary) Semaphores and showed that a Semaphore easily solves the critical section problem and doesn't require knowledge of how many processes are competing for the critical section. We gave an implementation using Test-and-Set.

We then gave an operational definition of Semaphore (which is not an implementation) and morphed this definition to obtain a Counting (or Generalized) Semaphore, for which we gave NO implementation. I asserted that a counting semaphore can be implemented using 2 binary semaphores and gave a reference.

We defined the Readers/Writers (or Bounded Buffer) Problem and showed that it can be solved using counting semaphores (and binary semaphores, which are a special case).

Finally we briefly discussed some classical problem, but did not give (full) solutions.

2.5: Process Scheduling

Scheduling processes on the processor is often called “process scheduling” or simply “scheduling”.

The objectives of a good scheduling policy include

• Fairness.
• Efficiency.
• Low response time (important for interactive jobs).
• Low turnaround time (important for batch jobs).
• High throughput [the above are from Tanenbaum].
• More “important” processes are favored.
• Interactive processes are favored.
• Repeatability. Dartmouth (DTSS) “wasted cycles” and limited logins for repeatability.
• Fair across projects.
  • “Cheating” in unix by using multiple processes.
  • TOPS-10.
  • Fair share research project.
• Degrade gracefully under load.

Recall the basic diagram describing process states

For now we are discussing short-term scheduling, i.e., the arcs connecting running <--> ready.

Medium term scheduling is discussed later.

Preemption

It is important to distinguish preemptive from non-preemptive scheduling algorithms.

• Preemption means the operating system moves a process from running to ready without the process requesting it.
• Without preemption, the system implements “run to completion (or yield or block)”.
• The “preempt” arc in the diagram.
• We do not consider yield (a solid arrow from running to ready).
• Preemption needs a clock interrupt (or equivalent).
• Preemption is needed to guarantee fairness.
• Preemption is found in all modern general purpose operating systems.
• Even non preemptive systems can be multiprogrammed (e.g., when processes block for I/O).

Deadline scheduling

This is used for real time systems. The objective of the scheduler is to find a schedule for all the tasks (there are a fixed set of tasks) so that each meets its deadline. The run time of each task is known in advance.

Actually it is more complicated.

• Periodic tasks
• What if we can't schedule all task so that each meets its deadline (i.e., what should be the penalty function)?
• What if the run-time is not constant but has a known probability distribution?

We do not cover deadline scheduling in this course.

The name game

There is an amazing inconsistency in naming the different (short-term) scheduling algorithms. Over the years I have used primarily 4 books: In chronological order they are Finkel, Deitel, Silberschatz, and Tanenbaum. The table just below illustrates the name game for these four books. After the table we discuss each scheduling policy in turn.

Finkel  Deitel  Silbershatz Tanenbaum
-------------------------------------
FCFS    FIFO    FCFS        FCFS
RR      RR      RR          RR
PS      **      PS          PS
SRR     **      SRR         **    not in tanenbaum
SPN     SJF     SJF         SJF
PSPN    SRT     PSJF/SRTF   --    unnamed in tanenbaum
HPRN    HRN     **          **    not in tanenbaum
**      **      MLQ         **    only in silbershatz
FB      MLFQ    MLFQ        MQ

Remark: For an alternate organization of the scheduling algorithms (due to Eric Freudenthal and presented by him Fall 2002) click here.

First Come First Served (FCFS, FIFO, FCFS, --)

If the OS “doesn't” schedule, it still needs to store the list of ready processes in some manner. If it is a queue you get FCFS. If it is a stack (strange), you get LCFS. Perhaps you could get some sort of random policy as well.

• Only FCFS is considered.
• Non-preemptive.
• The simplist scheduling policy.
• In some sense the fairest since it is first come first served. But perhaps that is not so fair--Consider a 1 hour job submitted one second before a 3 second job.
• The most efficient usage of cpu since the scheduler is very fast.

Round Robin (RR, RR, RR, RR)

• An important preemptive policy.
• Essentially the preemptive version of FCFS.
• Note that RR works well if you have a 1 hr job and then a 3 second job.
• The key parameter is the quantum size q.
• When a process is put into the running state a timer is set to q.
• If the timer goes off and the process is still running, the OS preempts the process.
  • This process is moved to the ready state (the preempt arc in the diagram), where it is placed at the rear of the ready list.
  • The process at the front of the ready list is removed from the ready list and run (i.e., moves to state running).
  • Note that the ready list is being treated as a queue. Indeed it is sometimes called the ready queue, but not by me since for other scheduling algorithms it is not accessed in a FIFO manner.
• When a process is created, it is placed at the rear of the ready list.
• As q gets large, RR approaches FCFS. Indeed if q is larger that the longest time a process can run before terminating or blocking, then RR IS FCFS. A good way to see this is to look at my favorite diagram and note the three arcs leaving running. They are “triggered” by three conditions: process terminating, process blocking, and process preempted. If the first condition to trigger is never preemption, we can erase the arc and then RR becomes FCFS.
• As q gets small, RR approaches PS (Processor Sharing, described next)
• What value of q should we choose?
  • Trade-off
  • Small q makes system more responsive, a long compute-bound job cannot starve a short job.
  • Large q makes system more efficient since less process switching.
  • A reasonable time for q is about 1ms (millisecond = 1/1000 second). This means each other job can delay your job by at most 1ms (plus the context switch time CS, which is much less than 1ms). Also the overhead is CS/(CS+q), which is small.

Homework: 26, 35, 38.

Homework: Give an argument favoring a large quantum; give an argument favoring a small quantum.

Process	CPU Time	Creation Time
P1	20	0
P2	3	3
P3	2	5

Homework: (Remind me to discuss this last one in class next time): Consider the set of processes in the table below. When does each process finish if RR scheduling is used with q=1, if q=2, if q=3, if q=100. First assume (unrealistically) that context switch time is zero. Then assume it is .1. Each process performs no I/O (i.e., no process ever blocks). All times are in milliseconds. The CPU time is the total time required for the process (excluding any context switch time). The creation time is the time when the process is created. So P1 is created when the problem begins and P3 is created 5 milliseconds later. If two processes have equal priority (in RR this means if thy both enter the ready state at the same cycle), we give priority (in RR this means place first on the queue) to the process with the earliest creation time. If they also have the same creation time, then we give priority to the process with the lower number.