CS162 Lecture 4: Monday, January 31, 2005 Annoucement: - Buy book if you want them now. - Read handout before asking questions. - You may post your hw1 statistics on the newsgroup. - If you have not signed up for lecture notes, contact the professor. - Section 103 has been moved to Thursday 5-6pm at 187 Dwinelle, Adrian will lead it. TOPIC: - CPU Scheduling continued - Independent and Cooperating Process ------- Topic 1: CPU Scheduling Continued - SET(Shortest Elapsed Time): At any time, work on the job that has received the least amount of service at that time. Note that by the nature of the algorithm, at any time if two of more jobs have the least amount of service, then they continue to have the least amount of service and share the processor equally until a newjobs arrives + Advantage - Permits short jobs to get out fast. - Variance of f(i) low. - Disadvantage - High overhead. Very bad if run time distribution is highly skewed. - Foreground/Background (F/B) scheduling: have two queues - Created for situations in which processes are easily classified into different groups. +-------------------+ | | |> -----+ FG +-+ | +----> ||||----->| |-----> Jobs | | -----+ +-+ Finished jobs ---->| | | | | | | |> -----+ | +-----> ||||-----+ -----+ BG *** F/B Scheduling +-------------------+ | | | -----+ +-+ | +----> ||||----->| |-----> Jobs | -----+ +-+ Finished jobs ---->| ^ | | | -----+ | +-----> ||||------+ | -----+ . . . . . . . . . ^ | | | -----+ | +-----> ||||------+ -----+ --- Multilevel Queue-Scheduling - Foreground queue (FG) has priority over the background queue (BG). - Interactive processes go to foreground queue, cpu-bound processes go into background. - Any scheduling algorithm can be used for each of the queue. - Typically involves timeslices. - Jobs assignment to FG or BG can be decided in various way. - Good performance. - Multilevel Foreground/Background (MLFB) Scheduling: like F/B, but with several queues not just two - Jobs can be assigned to a level based on any criteria.e.g.priority, runtime etc. - Exponential Queue Scheduling: A special type of MLFB queue, also called multilevel feedback queue. - Allows a process to move between queues. - Give newly runnable process a high priority, new process has high priority and short time slice. - Decrease prio. and increase timeslice after process uses up quantum - Multiple queues representing different job types. - batch, interactive, system, CPU-bound, etc. - Queues have priorities. - Jobs move between queues based on execution history. - 'feedback': switch from CPU-bound to interactive behavior. - Generally, an Exponential Queue scheduler is defined by thefollowing parameters: - The number of queues. - The scheduling algorithm for each queue. - The method used to determine when to upgrade a process to a higher- priority queue. - The method used to determine when to demote a process to a lower- priority queue. - The method used to determine which queue a process will enter when that process needs service. - Adaptive Scheduling Algorithm: change the priority of jobs depending on the runtime behavior - Another "Fair-share" scheduling - Keep history of recent CPU usage for each process. - Give highest prio. to process with low CPU time usage and vice versa. - BSD Unix Scheduling - 4 classes spanning 128 priority levels - Runs job from highest priority queue. - Each queue is Round-Robin (q = 0.1 sec). - 0-49 reserved for supervisor procedure. - 50-127 reserved for user procedure . - User priority = PUSER+PCPU+PNICE - PUSER : depend on type of user. - PCPU : based on CPU time used. more time used -> switch to lower priority queue - PNICE : allow job decrease in priority. ---> Joke: KISS = Keep it Simple Stupid - Scheduling Countermeasures: How to make the scheduling algorithm perform poorly - Break up big job into several small jobs. - Do spurious I/O (dummy I/O). - Summary: In principle, scheduling algorithm can be arbitrary - The best schedules are adaptive and preemptive. To do absolutely best, we'd have to be able to pridict future. - Best scheduling algorithm tend to give highest priority to the process that need the least. --------- Topic 1.5 Discrete Event Simulation: - Event List. - Loop: (get event) (reset clock to event time) (update system statistics) (update system state) (generate any new events and put them on event list) (continue loop). --------- Topic 2: Independent and Cooperating Process - Independent process: one that can't affect or be affected by the rest ofthe universe. - Its state isn't in any way by any other process. - Deterministic and Reproducible: input state above determines results. - Can stop and restart with no bad effects. - How often are process independent? - If a process shares a file with another process, it isn't independent - If one use input from another, generates output for another, it isn't - If they have conflicts in the resource they want to use, they aren't - If they are part of the same command, they aren't independent. - Indep. process are interesting and useful from the viewpoint of scheduling - Cooperating process: - Cooperating processes are those share the same states. - We are interested in the results of the computation. - We are therefore interested in reproducible results despite the fact that some aspects of non-deterministics. - Suppose we start with a quiescent machine with the same starting condition, will the same things happen? - If you do I/O, can you guarantee same angular position on the head? - Writing to disk requires the freelist to have the same blocks in thesame size and in the same order. - If you use the clock, then the clock must be set to exact same value. - Essentially: What we really want is same MACRO behavior but notnecessarily same Micro behavior - Micro level behavior. - Macro level behavior. - It is important that the results of the computation be reproducible. - Why permit processes to cooperate? - Want to share resources - One computer, many users. - One file of checking account records many tellers. - Want to do things faster - Need next block while proving current one. - Divide job into sub-jobs execute in parallel. - Want to construct system in modular fashion - A counting contest ProA ProB i=0; i=0; while (i<10) i=i+1; while (i>-10) i=i-1; printf("A is done"); printf("B is done"); - variable i is shared - Ref. (read) and assignment are each atomic - Will process A or process B win? - Will they ever finished? Note that even if they run at exactly the same speed, one might still win. Note the effect of --readA, readB, writeB, writeA-- - If one finishes, will the other also finish? - When discussing concurrent process, multiprogramming is as dangerous as multiprocessing unless you have right control over the multiprogramming - In general, in our dis. we can assume that at any instant, if two processes are ready, the processor can switch from running one to running the other. - Atomic operation - In order to sychronize parallel processes, we will need atomic operations - Atomic operation: without interruption, can not be interrupted. - loads and store are atomic in almost all systems - If you turn off interrupts on computers, it is sort of atomic. ---Too Much Milk Problem: roommate A and B - Motivation: A 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 Buy milk. Leave for store. 3 : 20 Arrive home, put milk away. Arrive at store. 3 : 25 Buy milk. 3 : 30 Arrive home, put milk away. Oh no! Too much milk!!! - Synchronization: using atomic operations to ensure cooperation between threads - Mutual exclusion: ensuring that only one thread does a particular thing at a time. One thread doing it excludes the other, and vice versa. - Critical section: piece of code that only one thread can execute at once. Only one thread at a time will get into the section of code. - Lock: prevents someone from doing something. 1. Lock before entering critical section, before accessing shared data 2. unlock when leaving, after done accessing shared data 3. wait if locked - Solution 1: For both A and B if (noMilk) { if (noNote){ leave Note; buy milk; remove note; } } ---Why doesn't this work? Thread can get context switched after checking milk and note, but before buying milk! - Solution 2: A B if (noNote) { if (Note) { if (noMilk){ if (noMilk){ buy milk; buy milk; leave note; remove note; } } } } ---Why doesn't this work? Only one process will buy milk. This could lead to indefinite waiting, due to B taking a vacation. So it fails a quirement: if there is no milk somebody will buy one. - Solution 3: A B Leave note A Leave note B if (noNote B) { if (noNote A) { if (noMilk){ if (noMilk){ buy milk; buy milk; } } } } Remove note A Remove not B ***Why doesn't this work? Possible for neither thread to buy milk; context switches at exactly the wrong times can lead each to think the other is going to buy. Illustrates s t arva t i on : thread waits forever - Solution 4: A B Leave note A Leave note B while (noteB) wait; --X if (noNote A) {--Y if (noMilk) { if (noMilk){ buy milk; buy milk; } } } Remove note A Remove note B Does this work? Yes. Can guarantee at X and Y that either - safe for me to buy - other will buy, ok to quit - At Y: if noNote A, safe for B to buy (means A hasn't started yet) if note A, A is either buying, or waiting for B to quit, so ok for B to quit - At X: if nonote B, safe to buy if note B, don't know. A hangs around. Either: - if B buys, done - if B doesn't buy, A will.