Sherman Lee Lecture: Monday, January 31, 2005 Announcement: Publish results of Assignment 1 on the newgroup is okay. Write small data you can calculate by hand. Will post things rougly every 3 lectures on website. Will update everything before midterms. TOPIC: CPU Scheduling continued Foreground/Background (FB) Scheduling 1. Foreground/Background scheduling consists of two queues. - The first queue (which is the foreground) has priority over the second queue (which is the background). - see figure ---------------------------------- | | | FG | | -------- O O | |----| | | |---------->O O----------> ----| | | | O O | -------- ^ | | | BG | | -------- | -------|----| | | |-------------- | | | | -------- 2. You can use whichever scheduling algorithm you want for each of the queues. - Typically, a time slice is used. - Jobs that haave been running for a while are placed back into either the foreground or the background queue. 3. The assignment to the foreground or background queue can be decided in different ways. - interactive or batch - foreground (unix) or background (unix) - I/O intensive or computation intensive - newly arrived or long running - non deadline or deadline 4. The foreground/background scheduling allows good performance. - One can assign to the foreground or background based on performance considerations. - One can also use it to express priorities. Some people have important work to do. 5. Foreground/Background is a good way to get CPU - I/O overlap - One can put the I/O intensive processes in the foreground. Multilevel Foreground / Background (MLFB) 1. If FG/BG is good, then multilevel fg/bg must be better. - It is like foreground/background but several queues are used, not just two. ---------------------------------- | | | | | -------- O O | |--->| | | |---------->O O----------> | | | | | O O | -------- ^ | | | | | -------- | -------|--->| | | |-------------- | | | | | | | -------- | | . . | . . | . . | -------- |--->| | | |-------------| | | | | -------- 2. Jobs can be assigned to a level based on different criteria. - They could be run times, priorities, the use of I/O, etc. Exponential Queue 1. This is a special type of MLFB queue. It is also called multilevel feedback queues. 2. It gives a newly runnable process a high priority and a very short time slice. - If a process uses up the time slice without blocking then decrease the priority by 1 and double the time slice for next time. - The reason to increase the quantum is to decrease the overhead. This will give a highly skewed run time. - There is less switching and less overhead to reload into memory. - Once a job is promoted to the in-memory queue, let it run for a while to amortize overhead. 3. The CTSS SYSTEM (MIT, 1960s) was the first to use exponential queues. - It used four queues. - 1 time slice for the first queue,2 for the second, 4 for the third, and 8 for the fourth. - Jobs taken from the nth queue take 2^n time slices. 4. You can further adjust this algorithm by allowing the process to move up in priority the longer it waits. This is described below in fair share scheduling. - Something like this is used in TSO. - This is the general approach to avoiding starvation. - Low priorities move up with waiting time. Adaptive Scheduling Algorithms They are algorithms which change the priority of the job depending on its run time behavior. - examples are FB, MLFB, SET, Exponential Queue, etc. Fair-Share Scheduling 1. This another scheduling algorithm that is similar to what's used in VAX Unix 2. It keeps the history of recent CPU usage for each process. 3. It gives the highest priority to processes that has used the least amount of CPU time recently. - Highly interactive jobs, like vi, will use little CPU time and get high priority. - CPU-bound jobs, like compiles, will get lower priority. 4. We could use a formula like: priority = wait_time - 10*cpu_use - TSO uses something similar to this. 5. We can adjust priorities by changing "billing factors" for processes. - To make a high-priority process, only use half its recent CPU usage in computing history. 6. A fair share scheduler can be implemented in an MLFB or Exponential queue system by promoting jobs as they wait and demoting them as they use CPU time. BSD Unix Scheduling 1. BSD Unix uses multilevel feedback queues. - There are 128 priority levels. - To minimize overhead, processes are grouped into groups of 4 levels. - Thus, this is implemented with 32 queues. 2. The system runs the job at the front of the highest priority occuppied queue. - The job is run for a quantum. - When a job is done with its quantum, it is put on the back of the same queue. - The time quantum for 4.3 BSD is 0.1 seconds. This was foudn to be the longest time that didnt' produce a jerky response. - A higher priority process is only started when the quantum of the currently running process ends. However, a sleeping process that wakes up can preempt the running process after a system call. 3. User priority = PUSER + PCPU + PNICE - PUSER - This is based on the type of user. - For example, OS processes are higher priority. - PCPU - This is the weighted load factor that increases as this uses CPU time (uses decay filter) (type "uptime") - PNICE - This is the number that can be used to "nice" a job. - "nice" is reducing in priority 4. Priority levels 0-49 are reserved for ssytem processes. 50-127 are for user processes. 5. Hypothesis - DEC Unix uses very large quantum for workstations. Question: Do complicated algorithms use more overhead? Answer: Not so muhc overhead, but the problem is getting them right. KISS - keept it simple stupid. Schedule algorithms only help a margin. For example, you can't feed a sandwhich to 100 people no matter how you cut it. Scheduling Countermeasures (Don't do these things) 1. Most succesful scheduling algorithms assume that there are lots of short jobs and a few very long jobs. This gives priority to short jobs. 2. A general approach to "beating" scheduling algorithms is to make long jobs look like a lot of short jobs. - one big compile -> many small compiles - one big troff -> many small troffs - one big print job -> many small print jobs 3. Do spurious I/O (to /dev/null) to get promoted to higher queue. - This is considered antisocial - don't do it! Summary 1. In principle, scheduling algorithms can be arbitrary. The system should produce the same result in any event. 2. However, the algorithms have strong effects on the system's overhead, throughput, and response time. 3. The best schemes are adaptive and preemptive. To do absolutely best, we'd have to be able to predict the future. The best scheduling algorithms tend to give highest priority to the processes that need the least CPU time! Bank queue: Someone who deposits a check will be really quick. However, someone who wants to buy 6 months of travellers check takes long. Discrete Event Simulation Event List - list of events schedules to happen Loop - Get event, update stats, update state, update event list, continue TOPIC: Independent and Cooperating Processes Independent Process 1. It is one that can't affect or be affected by the rest of the universe. Few processes are really completely independent. 2. Its state isn't shared in any way by any other processes. - This is the major requirement for being independent. 3. Deterministic and Reproducible - This means that input state alone determines result. 4. They can stop and restart with no bad effects. Only time varies. - Example: a program that sums the integers from 1 to 100 The answer should be the same no matter how long it takes you. How often are processes independent? 1. If a process shares a file with another process, it isn't independent. 2. If one process uses input from another process or generates output for another, it isn't independent. 3. If processes conflict in the resources they want to use, they aren't independent. - Examples are printers, disks, tapes, etc. 4. If processes are part of the same command, they probably aren't independent. Independent Processes are interesting and useful from the viewpoint of scheduling. In real systems, however, there is usually some lack of complete independence. We are therefore going to concentrate on "cooperating processes" Cooperating Processes 1. Cooperating processes are those that share some state. 2. We are interested in the results of the computation. - If we want the sum of N numbers, that sum should always be computed correctly. Relative and absolute timing is not part of the results and can change from run to run. 3. We are therefore interested in reproducible results, despite the fact that some aspects of machine operation are non-deterministic. - Example: run times and relative interleaving of processes varies. 4. Suppose we start with a quiescent machine and the same starting conditions. Quiescent is when a machine is turned off in a cold room. We then plug it in and turn it on. Will the same things always happen? - This is a maybe. It is hard to get the same conditions. This requires that angular positions of all disks is the same. It will effect run time. - This requires that all system data structures be the same. The order of the job queue must be the same. - This requires that the disk layout be the same. This includes blocks, free lists, VTOCS (Volume Table of Contents), etc. - This may require that the system clock be set to the same value. - This requires that all electronic gates switch in just the same time, if this is a multiprocessor. Otherwise, the order of two processors could change. Micro Level Behavior versus Macro Level Behavior 1. Essentially, there is a distinction between micro level behavior and macro level behavior. For practical purposes, exact micro behavior is irreproducible. Macro behavior, on the other hand, should be reproducible. For example, the computation should produce the same results each time. 2. Micro level behavior is at the level of gates, the sequence of memory references at the CPU, etc. 3. It is important that results of computations be reproducible, despite considerable shared state, such as file system. Why permit processes to cooperate? 1. If you want to share resources - One computer, many users. - One file of checking account records, many tellers. 2. If you want to do things faster. - Reading the next block while processign the current one. - Dividing jobs into sub-jobs, and execute in parallel. 3. If you want to construct systems in modular fashion. - Piping results from one to the next. A counting contest Process A Process B i = 0; i = 0; while (i < 10) i = i+1;while (i > -10) i = i-1; printf(``A is done''); printf(``B is done''); 1. The variable i is shared. 2. Reference (read) and assignment are each atomic operations. 3. Will process A or B win? 4. If one finishes the other will also finish. 5. It doesn't help A to get a head start. It depends on the exact sequence. The sequence of read, read, write, write allows B to win. Multiprogramming - multiple processes running on the same processor concurrently. Multiprocessing - multiple processes, sharing memory When discussing concurrent processes, multiprogramming is as dangerous as multiprocessing unless you have tight control over the multiprogramming. Smart I/O devices are as bad as cooperating processes (they share the memory). - We can assume that at any instand, if two processes are ready, the processor can switch from running one to running the other. Only true atomic operations can't be interrupted. Atomic Operations 1. In order to synchronize parallel processes, we need atomic operations. 2. Atomic Operation - an operation that either happens in its entirety without interrupts or not at all. It can't be interrupted in the middle. 3. Loads and assignments (stores) are atmoic in almost all systems. - A=B will always get a good value for B, will always set a good value for A. - A=B consists of Load(B), store into A. - Load and Store are atomic. - A=B is atomic because Store(B) is atomic. 4. In uniprocessor systems, turning off interrupts can make what is between off/on atomic. 5. If you do not have any atomic operation, you can't make one. 6. The hardware guys give us atomic operations. 7. Having any atomic operation will allow you to use it to generate higher level contstructs and make parallel programs work correctly. TOPIC: Synchronization The ``too much milk'' problem: Person A Person B 3:00 Look in fridge. Out of milk. 3:05 Leave for store. 3:10 Arrive at store. Look in fridge. Out of milk. 3:15 Leave store. Leave for store. 3:20 Arrive home, put milk away. Arrive at store. 3:25 Leave store. 3:30 Arrive home. Too much milk. The problem here is that we want exactly one milk and not 0 or 2. 1st Attempt at computerized milk buying Processes A & B 1 if (NoMilk) 2 { 3 if (NoNote) 4 { 5 Leave Note; 6 Buy Milk; 7 Remove Note; 8 } 9 } This does not work because a sequence of operations can be interrupted at any time. Other processes can then be started. For example, the following sequence could occur. A1 A2 A3 A4 B1 B2 B3 B4 B5 B6 We are trying to synnchronize A and B. One of the most important things in synchronization is to figure otu what you want to achieve. Synchronization - using atomic operations to ensure correct operation of cooperating processes Mutual Exclusion - It is a mechanism that ensure that only one person or process is doing certain things at one time. For example, we could have only one person shopping at a time. Those things for which one wants exclusion is called critical section. Critical Section - A section of code, or collection of operations where only one process can execute at a given time. An example of this would be shopping. A critical section is the code that manipulates shared state. Only one process can manipulate the state at one time. There are different way of achieving exclusion. Most of them involve some sort of locking mechanism to prevent someonoe from doing something. For example, before shopping we could leave a note on the refridgerator. There are three elements of locking. 1. You must lock before using/doing (leave note) 2. You must unlock when you are done(remove note) 3.. You ust wait if locked. (don't shop if there's a note) The locking solution works for peopel because you'll see the other person at the refridgerator and make arrangements. However, computers don't look for the other person and leave the note at the same time. 2nd Attempt at computerized milk buying We can change the meaning of the note. A buys if there is no note, B buys if there is a note. Process A 1 if (NoNote) 3 if (NoMilk) 5 Buy Milk; 7 Leave Note; Process B 1 if (Note) 3 if (NoMilk) 5 Buy Milk; 7 Remove Note; A and B will buy milk alternately. - A note will be left only by A, and only if there isn't already a note. - A note will be removed only by B, and only if there is a note. - Thus, there is either one note, or no note. - If there is a note, only B will buy milk. - If there is not a note, only A will buy milk. - Thus, only one process will buy milk. What if B goes on vacation and is gone for a very long time? A will buy milk once and won't buy any more until B returns. This will lead to starvation. Conditions for correctness - If there is no milk, someone will buy it. There is no indefinite waiting. This means no deadlocks. - At most only one milk will be purchased. 3rd attempt at computerized milk buying use 2 notes Process A 1 Leave NoteA; 2 if (NoNoteB) 3 { 4 if (NoMilk) 5 { 6 Buy Milk; 7 } 8 } 9 Remove NoteA; Process B 1 Leave NoteB; 2 if (NoNoteA) 3 { 4 if (NoMilk) 5 { 6 Buy Milk; 7 } 8 } 9 Remove NoteB; - At most only one person will buy milk. Each process will leave a note before it checks. - If one persong goes on a long vacation after step 9, the other process will still buy milk. - However, what if A and B leave notes at exactly the same time. Nobody will buy milk. There is still starvation. Now we just need a way to decide who will buy milk when both leaves notes. 4th attempt at computerized milk buying in the event of a tie, A will buy the milk Process A 1 Leave NoteA; 2 while (NoteB) DoNothing; 3 if (NoMilk) 5 Buy Milk; 7 Remove NoteA; Process B 2 Leave NoteB; 3 if (NoNoteA) 4 if (NoMilk) 6 Buy Milk; 7 Remove NoteB; This solution works but it still has some disadvantages 1. A might have to wait while B is at the store 2. While A is waiting it is consuming resources. 3. There is a possibility of "death" in the critical section. 4. This solution doesn't account for the possibility of 3 or more roomates.