Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
OPERATING SYSTEMS DESIGN AND IMPLEMENTATION Third Edition ANDREW S. TANENBAUM ALBERT S. WOODHULL Chapter 2 Processes The Process Model (1) Figure 2-1 (a) Multiprogramming of four programs. The Process Model (2) Figure 2-1 (b) Conceptual model of four independent, sequential processes. The Process Model (3) Figure 2-1 (c) Only one program is active at any instant. Process Creation Principal events that cause processes to be created: 1. System initialization. 2. Execution of a process creation system call by a running process. 3. A user request to create a new process. 4. Initiation of a batch job. Process Termination Conditions that cause a process to terminate: 1. Normal exit (voluntary). 2. Error exit (voluntary). 3. Fatal error (involuntary). 4. Killed by another process (involuntary). Process States (1) Possible process states: 1. Running (actually using the CPU at that instant). 2. Ready (runnable; temporarily stopped to let another process run). 3. Blocked (unable to run until some external event happens). Process States (2) Figure 2-2 A process can be in running, blocked, or ready state. Transitions between these states are as shown. Process States (3) Figure 2-3 The lowest layer of a process-structured operating system handles interrupts and scheduling. Above that layer are sequential processes. Implementation of Processes Figure 2-4. Some of the fields of the MINIX 3 process table. The fields are distributed over the kernel, the process manager, and the file system. Process States (2) What causes (1) to occur? – Process makes blocking system call – wait for event What causes (2)? – Process runs out of time quantum What causes (3)? – Scheduler picks the ready process to get CPU, dispatches it What causes (4)? – Event process was waiting on occurs – often an interrupt Stack needed By service routine Interrupts In table of addresses indexed by interrupt # pointing to handler code Figure 2-5 Skeleton of what the lowest level of the operating system does when an interrupt occurs. Threads (1) Figure 2-6 (a) Three processes each with one thread. Thread is a sequence of instruction execution – a path through the code is the static version of this – that is running (has state) Each thread has its own program counter and registers, etc. Threads (1.5) Process creation: Expensive (copy entire image) Often run same code – can save space and time if text segment is shared Often want shared objects as well – for coordination and for communication => Share data segment as well (less copying) Child process shares same owner, etc. - much of process table entry is also shared Threads - “Lightweight processes” Idea is to copy only what must be individual to separate execution sequence: stack, program counter, etc. Much faster to create and destroy Threads (2) Figure 2-6 (b) One process with three threads. Each thread has its own program counter and registers, etc. Threads (3) Figure 2-7. The first column lists some items shared by all threads in a process. The second one lists some items private to each thread. Race Conditions Figure 2-8 Two processes want to access shared memory at the same time. Race Conditions PrintServ outPS=4 Spooler directory out = 4 inPS=6 ... in = 8 6 7 Process A File 53 inA=8 inA=7 inA=6 Process B 4 File 1 5 File 2 6 File 3 7 8 File 5 4 inB=7 inB=8 File 4 Figure 2-8 Two processes want to access shared memory at the same time. Race Condition Example Load–Store atomicity: Loads and stores occur atomically X = X+1 translates to machine instructions: – – – Load X location contents into register increment register store register in X location Lost Update: P1 runs and loads X; P2 runs and loads X, increments register, stores into X; P1 runs again, increments register, stores into X Race Condition Example (2) P1 Load A, X P2 Load A, X Incr A Sto A, X Incr A Sto A, X If initial value of X was 0, final value of X is 1, not 2. Critical Sections Necessary to avoid race conditions: 1. No two processes may be simultaneously inside their critical regions. (Safety) 2. No assumptions may be made about speeds or the number of CPUs. 3. No process running outside its critical region may block other processes. (Liveness) 4. No process should have to wait forever to enter its critical region. (Liveness) Synchronization Criteria Safety – what MUST NOT happen to avoid disaster – e.g., No two processes may be simultaneously inside their critical regions Liveness – what MUST happen to keep everyone happy – – e.g., No process running outside its critical region may block other processes e.g., No process should have to wait forever to enter its critical region The exact nature of these depend on system, but generally want to avoid deadlock and starvation Deadlock = no processes can proceed Starvation = some process waits indefinitely Synchronization Code Generic Structure of a Process using a CS: Process () { while (TRUE) { Other() /* arbitrarily long time outside CS */ Entry() /* code to make sure it's OK to enter */ Critical Section() /* risky business */ Exit() /* code to let others know I'm done */ } } Synchronization Code Generic Code for a System of Processes: Main () { init_vars() /* initialize shared variables */ for (i=0; i<NUM_PROCS; i++) { StartProc(i) /* fork and run process i */ } for (i=0; i<NUM_PROCS; i++) { WaitProc(i) /* wait for process i to terminate */ } } Processes may all be the same, or they may be of various types (depending on nature of system), or they may do one thing sometimes and something else other times; BUT they all execute entry and exit codes for critical sections Mutual Exclusion Figure 2-9 Mutual exclusion using critical regions. Synchronization Mechanisms Basic flavors of synchronization mechanisms: Busy waiting (spin locks) – S/W or H/W based Semaphores (scheduling based) – OS support Monitors – language support Message-based – OS support ... others as well ... Mutual Exclusion with Busy Waiting With busy waiting, B may be using the CPU while “blocked” and so A can't leave critical region (until A gets CPU) Mutual Exclusion with Busy Waiting A enters critical region A's quantum runs out A leaves critical region Process A B's quantum runs out B tries to enter critical region B enters critical region Process B T1 T2 T3 B wastes CPU time busy waiting T4 T5 B leaves critical region With busy waiting, B may be using the CPU while “blocked” and so A can't leave critical region (until A gets CPU) Strict Alternation Where is entry code? Tight spin on turn Where is exit code? What is so bad about this solution? Figure 2-10. A proposed solution to the critical region problem. (a) Process 0. (b) Process 1. In both cases, be sure to note the semicolons terminating the while statements. Peterson’s Solution (1) { ... Figure 2-11 Peterson’s solution for achieving mutual exclusion. Peterson’s Solution (2) Figure 2-11 Peterson’s solution for achieving mutual exclusion. H/W: The TSL Instruction Figure 2-12. Entering and leaving a critical region using the TSL instruction. Generic Synchronization Code Process (i) { while (TRUE) { Other(i) /* arbitrarily long time outside CS */ Entry(i) /* code to make sure it's OK to enter */ Critical Section() /* risky business */ Exit(i) /* code to let others know I'm done */ } } Key point: Often want to allow multiple processes to do dangerous stuff at the same time, but the entry and exit code prevents bad stuff from happening – i.e., not always critical region problem Classic Synchronization Problems Critical Section Problem: Mutual exclusion – only one process can be in CS at a time Producer-Consumer Problem: Producers can write items into buffers at the same time Consumers are consuming other items, but two Producers must not write into same buffer at the same time, two Consumers must not consume the same item, and a Consumer must not consume an item until a Producer has finished writing it, nor may a Producer write an item into a buffer before a Consumer has finished emptying that buffer Bounded Buffer Problem: P-C with finite # buffers Readers-Writers: Any number of readers can read from a DB simultaneously, but writers must access it alone Dining Philosophers: See below The Producer-Consumer Problem (1) ... Figure 2-13. The producer-consumer problem with a fatal race condition. The Producer-Consumer Problem (2) ... So what is (are) the problem(s)? Figure 2-13. The producer-consumer problem with a fatal race condition Flaws in P-C Solution Several ways things can go wrong: 1 – Corrupt shared variables indicating how many empty buffers and/or how many full buffers there are 2 – Two producers try to fill same buffer 3 – Two consumers try to empty same buffer 4 – Producer and consumer try to access same buffer Semaphores Semaphores are a special type of shared memory: 1 – A semaphore S can only be declared and initialized, or accessed by Up(S) or Down(S); NO direct access 2 – When Down(S) is called, if S > 0, S-- and continue; otherwise block the caller and put on S's queue Q 3 – When Up(S) is called, if Q empty, S++ and continue; otherwise remove a process P from Q and unblock P 4 – Up() never blocks 5 – A process blocked on Down() does not use the CPU Semaphores Types and Uses Binary Semaphores: take only values 0 or 1 Uses: – Initialized to 1, used for mutual exclusion (a process does Down(mutex); CS; Up(mutex) ) – Initialized to 0, used for synchronization (one process does Down(S) to wait for another process to reach a point in its code where it does Up(S) ) Multivalued Semaphores: take integer values >= 0 Uses: – Initialized to N, where N is the number of instances of a shared resource – Up(S) to release an instance, Down(S) to take one The Producer-Consumer Problem (3) ... Figure 2-14. The producer-consumer problem using semaphores. The Producer-Consumer Problem (4) ... Figure 2-14. The producer-consumer problem using semaphores. Comments on P-C Solution Concurrency issues solution must handle: 1 – Corrupt shared variables indicating how many empty buffers and/or how many full buffers there are 2 – Two producers try to fill same buffer 3 – Two consumers try to empty same buffer 4 – Producer and consumer try to access same buffer Semaphore solution given solves (1) by ... counting semaphores, solves (2)-(4) by using a mutex Timing Diagram of P-C Soln P1 P2 P3 C1 C2 C1 must wait for a full buffer; P2 (et al.) must wait for P1 to finish copying item into buffer1; P3 must wait until there is an empty buffer, etc. Running/ready outside CS Blocked waiting for CS Running/ready inside CS Comments on P-C Solution (2) But solution does not permit maximum concurrency: only one process can insert or remove item at a time Why is this potentially an issue? What if items are very large, and take a long time to insert or remove? So, what can we do about it???? Better P-C Solution Producer() { while (TRUE) { Produce(item) /* arbitrarily long time */ Get_Empty(&buffer) /* find an empty buffer */ CopyTo(item,&buffer) /* could take a while */ Alert_Full(&buffer) /* tell consumers */ } } Consumer() { while (TRUE) { Get_Full(&buffer) /* find a full buffer */ CopyFrom(item,&buffer) /* could take a while */ Alert_Empty(&buffer) /* tell consumers */ Consume(item) /* arbitrarily long time */ } } Better P-C Solution (2) Get_Empty(&buffer) { down(&empty) /* wait for empty buffer to be available */ down(&mutex) /* only one process touches control vars */ buffer=find_empty_buffer() /* find a buffer marked empty*/ Mark_Busy(&buffer) /* buffer is neither full nor empty */ up(&mutex) } Alert_Full(&buffer) { down(&mutex) /* only one process touches control vars */ Mark_Full(&buffer) /* this buffer is full */ up(&mutex) up(&full) /* let consumers know a full buffer is available */ } Better P-C Solution (2) Get_Full(&buffer) { down(&full) /* wait for an item to be available */ down(&mutex) /* only one process touches control vars */ buffer=find_full_buffer() /* find a buffer marked full */ Mark_Busy(&buffer) /* buffer is neither full nor empty */ up(&mutex) } Alert_Empty(&buffer) { down(&mutex) /* only one process touches control vars */ Mark_Empty(&buffer) /* this buffer is empty */ up(&mutex) up(&empty) /* let producers know an empty buffer is available */ } Timing Diagram Better P-C Soln Full: Empty: Busy: 0 0 0 01 0 01 0 00 1 1 1 1 1 2 3 5 4 3 22 2 22 2 23 3 2 2 1 2 2 2 0 1 2 32 3 32 3 32 1 2 2 3 2 1 0 Starting with N=5 Empty buffers P1 P2 P3 C1 C2 C1 must wait for a full buffer; P2 (et al.) must wait for P1 to find buffer1, but can find buffer2 while P1 fills buffer1, etc. Running/ready outside CS Running/ready buffer access Blocked waiting for CS Running/ready inside CS Comments on Better P-C Solution Semaphore solution only allows one process in the buffer store at a time (uses counting semaphores to make sure that they will find what they are after) Better P-C solution has copy operations OUTSIDE critical regions – allows multiple processes to access different buffers concurrently The two “Get” procedures must – – – Find an idle buffer in the right state (full or empty) Mark that buffer as BUSY so nobody else uses it Return location to caller The two “Alert” procedures must – – Mark buffer as FULL or EMPTY Signal other processes by up on counting semaphore All four Get and Alert procedures are themselves CS's But the Copy procedures are NOT exclusive! Monitors (0) Monitors are a language construct – With spin locks and semaphores, programmer must remember to obtain lock/semaphore, and to release the same lock/semaphore when done: this is prone to errors! – Monitor acts like an Abstract Data Type or Object – only access internal state through public methods, called entry procedures – Monitor guarantees that at most one process at a time is executing in any entry procedure of that monitor – What if a process can't continue while in entry proc? Condition Variables Monitors are a language construct – What if a process can't continue while in entry proc? – Condition “variables” local to monitor allow a process to block until another process signals that condition – Unlike semaphores, condition vars have NO memory! – If no process is waiting on the condition, signaling the condition variable has NO effect at all! – A process that waits on a condition variable can be awakened and resume execution in entry procedure – So what about the process that woke the waiting process up? - May force it to wait (on a stack), or - May require it to leave entry procedure Monitors (1) Figure 2-15. A monitor. Monitors (2) Figure 2-16. An outline of the producer-consumer problem with monitors. Only one monitor procedure at a time is active. The buffer has N slots Monitors (3) Figure 2-16. An outline of the producer-consumer problem with monitors. Only one monitor procedure at a time is active. The buffer has N slots Comments on Sync Mechanisms Shared memory solutions – either software only or hardware supported (TSL or swap) have spin-locks; shared memory location can be accessed directly (read/written); “blocked” process consumes CPU cycles Semaphores – requires OS support – scheduling based; semaphores CANNOT be accessed directly, only through UP() and DOWN(), and semaphore values are persistent; heavier cost than spin-lock code (system call); blocked process does not consumer CPU cycles Condition Variables – within monitor construct (language support needed); scheduling based (blocked process does not use CPU); condition “variables” are more like signals and queues – they are NOT persistent and can not be accessed directly, only through wait and signal Message Passing (1) ... Figure 2-17. The producer-consumer problem with N messages. Message Passing (2) ... Initialize system Figure 2-17. The producer-consumer problem with N messages. The Dining Philosophers Problem (1) Figure 2-18. Lunch time in the Philosophy Department. The Dining Philosophers Problem (2) Figure 2-19. A nonsolution to the dining philosophers problem. The Dining Philosophers Problem (3) ... Figure 2-20. A solution to the dining philosophers problem. The Dining Philosophers Problem (4) ... ... Figure 2-20. A solution to the dining philosophers problem. The Dining Philosophers Problem (5) ... Figure 2-20. A solution to the dining philosophers problem. The Readers and Writers Problem (0) Read-write and write-write conflicts cause race conditions Must avoid them! Reads do NOT conflict with other reads, are allowed. Reader can access database at same time, but writers must have exclusive access to it. Hence, readers get read locks and writers get write locks. Read locks are compatible with read locks, but not write locks Write locks are not compatible with read or write locks. Policy issues surround when readers can enter and who gets in next when a writer leaves. The Readers and Writers Problem (0.5) Lock type requested Lock type held None Read Write Read Yes Yes No Write Yes No No Lock Compatibility Matrix The Readers and Writers Problem (1) ... Figure 2-21. A solution to the readers and writers problem. The Readers and Writers Problem (2) ... Figure 2-21. A solution to the readers and writers problem. The Readers and Writers Problem (3) Possible policies for R/W problem Writer Leaving DB, Readers and Writers Waiting Reader in DB and Writer waiting Readers Enter Readers Wait Reader Preference Writer Preference Reader Enters Strong Reader Preference Makes no Sense ??? Enters Weak Reader Preference Fair policies possible Writer Enters Weaker Reader Preference Writer Preference More Readers and Writers Alpha-lock: tentative write lock used to increase concurrency for larger search structures Lock type held Lock type requested None Read Alpha Write Read Yes Yes Yes No Alpha Yes Yes No No Write Yes No No No Alpha Lock Compatibility Matrix Summary of Classical Synch Problems Critical Section Problem – Symmetric – simplest problem – mutual exclusion Producer-Consumer Problem – Asymmetric – wait on event from other type of process – also have mutual exclusion for access to buffers, control variables Dining Philosophers Problem – Symmetric – must wait for access to two resources – five is smallest interesting number of philosophers Reader-Writers Problem – Asymmetric – readers can share with each other, but not with writers, writers must have exclusive access – want maximum concurrency – many flavors depending on policies Need for Process Scheduling Recall process behavior... Figure 2-22. Bursts of CPU usage alternate with periods of waiting for I/O. (a) A CPU-bound process. (b) An I/O-bound process. For good resource utilization, want to overlap I/O of on process with CPU burst of another process When to Schedule When scheduling is absolutely required: 1. When a process exits. 2. When a process blocks on I/O, or a semaphore. i.e. - when the running process can no longer run! When scheduling usually done (though not absolutely required): 1. When a new process is created. 2. When an I/O interrupt occurs. 3. When a clock interrupt occurs. i.e., when another process has higher priority Scheduling Algorithm Goals Figure 2-23. Some goals of the scheduling algorithm under different circumstances. Three Level Scheduling (1) Short-term Long-term Medium-term Figure 2-25. Three-level scheduling. Three Level Scheduling (2) Criteria for deciding which process to choose: • How long has it been since the process was swapped in or out? • How much CPU time has the process had recently? • How big is the process? (Small ones do not get in the way.) • How important is the process? Three Level Scheduling (3) Main goal for long-term (admission) scheduler: • Get good mix of jobs in RAM Main goal for medium-term (memory) scheduler: • Prevent thrashing (more on this later) Main goals for short-term (CPU) scheduler: • Be efficient and fair All share goals of: Maximizing resource utilization Giving best service to clients Enforcing system policies Scheduling Algorithm Measures Turn-around time = Finish time – arrival time includes time spent waiting for CPU Mean Turn-around Time (MTT) Average TT over all jobs Fairness – various measures, including maximum difference in fraction of time each job got CPU over some period Makespan = Finish time of last job to finish – start time for set of jobs Used for multiprocessor scheduling Processor utilization = fraction of time CPU used Turn-around Time CPU time A B B takes 4 units of time if run by itself C Arrival time A takes 9 units of time if run by itself C takes 3 units of time if run by itself A A arrives at time 0 B arrives at time 1 B C C arrives at time 2 FCFS Schedule B arrives at time 1 C arrives at time 2 C must wait B must wait A finishes at time 9 B finishes at time 13 A running Now B can run Now C can run B waiting B running C finishes at time 16 C waiting C runs All done! Schedule A arrives at time 0 A gets CPU A B C MTT= (9+12+14)/3= 35/3 TT(A) = 9 – 0 = 9 TT(B) = 13 – 1 = 12 TT(C) = 16 – 2 = 14 Scheduling Algorithms Non-preemptive algorithms: Running job must give up CPU/system voluntarily First-Come First-Serve (FCFS): • Jobs run in order of arrival Shortest Job First (SJF): • Ready job that will finish first is run first Priority • Ready job with highest priority is run first Optimal (Crystal Ball) • Uses future knowledge of arrivals to optimize Shortest Job First A arrives at time 0, take 9 units A B arrives at time 1, takes 4 units B C arrives at time 2, takes 3 units C What is SJF Schedule? Schedule A arrives at time 0 A gets CPU C arrives at time 2 C must wait B arrives at time 1 B must wait A A A B B C C goes next – why? C has shorter run time A finishes at time 9 Who gets CPU next? A running B waiting wait… C waiting C runs TT(A) = 9 – 0 = 9 C finishes at time 12 Now B runs.. And finishes at time 16 B running TT(C) = 12 – 2 = 10 MTT= (9+10+15)/3= 34/3 TT(B) = 16 – 1 = 15 Optimal Non-preemptive A arrives at time 0, take 9 units A B arrives at time 1, takes 4 units B C arrives at time 2, takes 3 units C What is Optimal Schedule? (using MTT) Schedule A arrives at time 0 A waits! – Why? C arrives at time 2 C must wait – Why? B arrives at time 1 B runs A B C A A A waits A waits C goes next – why? C has shorter run time B finishes at time 5 Who gets CPU next? A running C finishes at time 8 Now A finally runs… and finishes at time 17 B B runs C waits C runs TT(B) = 5 – 1 = 4 TT(C) = 8 – 2 = 6 MTT= (4+6+17)/3= 27/3 TT(A) = 17 – 0 = 17 Scheduling Algorithms Preemptive algorithms: Running job may be forced to give up CPU/system involuntarily Round Robin (RR): • Jobs run in order of arrival, with maximum quantum (go to end of queue if preempted) Shortest Remaining Time First (SRTF): • Ready job that will finish first is run first Preemptive Priority • Ready job with highest priority is run first CTSS • Attempts to approximate SRTF SJF Scheduling Figure 2-24. An example of shortest job first scheduling. (a) Running four jobs in the original order (FCFS). (b) Running them in shortest job (SJF) first order. What is the mean turn-around time for the set of jobs? A:8, B:12, C:16, D:20 Mean = 56/4 = 14 A:20, B:4, C:8, D:12 Mean = 44/4 = 11 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Round-Robin Scheduling Figure 2-26. Round-robin scheduling. (a) The list of runnable processes. (b) The list of runnable processes after B uses up its quantum. For our problems in scheduling, if process C arrives at the same time that process D uses up its quantum, C will be added to the ready queue before D is added to it. Round-Robin Scheduling Process Name: Arrival Time (AT): CPU Burst Length (CT): A 0 8 Arrivals-> A E B C D B 2 5 C 3 1 D 5 2 E 7 2 Quantum = 1: A A B A C B A D B E A D B E A B A A A C B A D B E A D B E A B A B A D B E A D B E A B A D B E A Turnaround times: A:18-0, B:16-2, C:7-3, C:5-3, D:11-5, D:12-5, E: 15-7 14-7 Average TT = (18+14+4+6+8)/5 (18+14+2+7+7)/5 = 50/5 48/5 = 10 9.6 Quantum = 2: A A B B A A C B B D D A A E E B A A A A C C B D D A A E E B B A C B B D A A E E B B A A D A E E B B FCFS, SJF, SRTF Scheduling Process Name: Arrival Time (AT): CPU Burst Length (CT): A 0 8 B 2 5 C 3 1 D 5 2 E 7 2 FCFS Schedule: A A A A A A A A B B B B B C D D E E Turnaround times: A:8-0, B:13-2, C:14-3, D:16-5, E: 18-7 Average TT = (8+11+11+11+11)/5 = 52/5 = 10.4 SJF Schedule: A A A A A A A A C D D E E B B B B B Turnaround times: A:8-0, B:18-2, C:9-3, D:11-5, E: 13-7 Average TT = (8+16+6+6+6)/5 = 42/5 = 8.4 SRTF Schedule: A A B C B D D E E B B B A A A A A A Turnaround times: A:18-0, B:12-2, C:4-3, D:7-5, E: 9-7 Average TT = (18+10+1+2+2)/5 = 33/5 = 6.6 (Preemptive) Priority Scheduling Figure 2-27. A scheduling algorithm with four priority classes. Run a process at priority i+1 over any process at priority i Run processes at priority i in round robin (or whatever) order Preempt process if higher priority process arrives Priority Scheduling Process Name: Priority: Arrival Time (AT): CPU Burst Length (CT): A 4 0 8 B 2 2 5 C 3 3 1 D 1 5 2 E 5 7 2 Priority Schedule: A A B B B D D B B C A A A A A A E E Turnaround times: A:16-0, B:9-2, C:10-3, D:7-5, E: 18-7 Average TT = (16+7+7+2+11)/5 = 43/5 = 8.6 Priority is usually preemptive Scheduler is run whenever a process arrives Scheduler runs whenever a process unblocks Priority is most general policy It can model any other policy by priority definition CTSS Scheduling CTSS used by Multics OS – try to approximate SRTF Multi-level feedback queue – Enter at queue 0, drop to next queue if TRO Queue i gets 2i for time quantum, i = 0, 1, 2, ... Process Name: Arrival Time (AT): CPU Burst Length (CT): CTSS: A 0 8 AA B C A D B B C - D C 3 1 D 5 2 E B D E - - E 7 2 E AAAA BB A Q0 A - Q1 - AA A ABB = BB BBDD BDD BDDEE DDEE EE - . . . - . - Q2 - - - - - A4 = = = A4B4 = = . . . B4 . - Q3 - - - - - - - - - - . . . A8 . = - - B 2 5 - - - . . . - . - Turnaround times: A:18-0, B:17-2, C:4-3, D:10-5, E: 11-7 Average TT = (18+15+1+5+4)/5 = 43/5 = 8.6 Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8 Thread Scheduling • • • Recall that a thread is essentially an execution state within a process. Each thread has its own • PC • status register • Stack • State • priority, etc., But shares with the other threads in the same process • text segment, • data segment, • owner, group, • accounting information, etc. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8 Thread Scheduling • Two types of threads: • User-level threads – the OS only sees the parent process, and doesn’t know about individual threads. • Process is scheduled, not threads • Threads are handled by thread run-time support within process • One thread blocks => the whole process blocks. • Kernel threads – the OS knows about the threads and can schedule them independently, allow each to have its own state (e.g., one may be blocked, while another is running and others in the same “pod” are ready). Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8 Thread Scheduling (1) (a) Figure 2-28. (a) Possible scheduling of user-level threads with a 50-msec process quantum and threads that run 5 msec per CPU burst. Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13- Thread Scheduling (2) (b) Figure 2-28. (b) Possible scheduling of kernel-level threads with the same characteristics as (a). Multi-Core Thread Scheduling • • • User-level threads • OS sees only the process... • Can only schedule the process on one core • All threads in process run on same core Kernel threads • OS sees the threads (has a thread table in addition to process table) • Can schedule different threads from same process on different cores • Higher overhead for scheduling LWP/thread approach • Sun Microsystems provided for kernel threads (LWPs – essentially VMs) and user-level threads • Threads assigned to LWPs, LWPs assigned to cores Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved. 0-13-142938-8 The Internal Structure of MINIX Figure 2-29. MINIX 3 is structured in four layers. Only processes in the bottom layer may use privileged (kernel mode) instructions. MINIX 3 Startup Figure 2-30. Some important MINIX 3 system components. Others such as an Ethernet driver and the inet server may also be present. MINIX Memory (1) top half (See next slide) Figure 2-31. Memory layout after MINIX 3 has been loaded from the disk into memory. The kernel, servers, and drivers are independently compiled and linked programs, listed on the left. Sizes are approximate and not to scale. MINIX Memory (2) Figure 2-31. Memory layout after MINIX 3 has been loaded from the disk into memory. The kernel, servers, and drivers are independently compiled and linked programs, listed on the left. Sizes are approximate and not to scale. MINIX Header File Figure 2-32. Part of a master header which ensures inclusion of header files needed by all C source files. Note that two const.h files, one from the include/ tree and one from the local directory, are referenced. Sizes of Types in MINIX Figure 2-33. The size, in bits, of some types on 16-bit and 32-bit systems. MINIX Message Types Figure 2-34. The seven message types used in MINIX 3. The sizes of message elements will vary, depending upon the architecture of the machine; this diagram illustrates sizes on CPUs with 32-bit pointers, such as those of Pentium family members. Debug Dump Figure 2-35. Part of a debug dump of the privilege table. The clock task, file server, tty, and init processes privileges are typical of tasks, servers, device drivers, and user processes, respectively. The bitmap is truncated to 16 bits. Debug Dump ID 0 is for user processes (e.g., init server) P flag – is process/task preemptable? SRB traps – can process use send/receive/or send_rec? ipc_to mask – who can process send a message? Bootstrapping MINIX (1) Figure 2-36. Disk structures used for bootstrapping. (a) Unpartitioned disk. The first sector is the bootblock. Bootstrapping MINIX (2) Figure 2-36. Disk structures used for bootstrapping. (b) Partitioned disk. The first sector is the master boot record, also called masterboot. Boot Time in MINIX Figure 2-37. Boot parameters passed to the kernel at boot time in a typical MINIX 3 system. System Initialization in MINIX Figure 2-38. How alternative assembly language source files are selected. Interrupt Handling in MINIX (1) Figure 2-39. Interrupt processing hardware on a 32-bit Intel PC. Interrupt Handling in MINIX (2) Figure 2-40. (a) How a hardware interrupt is processed. Interrupt Handling in MINIX (3) Figure 2-40. (b) How a system call is made. Restart Figure 2-41. Restart is the common point reached after system startup, interrupts, or system calls. The most deserving process (which may be and often is a different process from the last one interrupted) runs next. Not shown in this diagram are interrupts that occur while the kernel itself is running. Queueing Process 3 tries to send to process 0, must wait. Process 4 also must wait. Figure 2-42. Queuing of processes trying to send to process 0. Scheduling in MINIX Low Idle process User processes Servers Priority Drivers High Kernel tasks Figure 2-43. The scheduler maintains sixteen queues, one per priority level. Shown here is the initial queuing process as MINIX 3 starts up. Hardware-Dependent Kernel Support Granularity (pages/bytes) SEGMENTS These are Hardware, not VM segments. GDT – global (points to LDTs) IDT – interrupts LDT – local (1 per process) Limit is 20-bit quantity of bytes or 4096-byte pages How can you tell which it is? Base is 32-bit quantity Why split up in such a funny way? Backward compatibility! Figure 2-44. The format of an Intel segment descriptor. Overview of System Task (1) Figure 2-45. The message types accepted by the system task. “Any” means any system process; user processes cannot call the system task directly Overview of System Task (2) Figure 2-45. The message types accepted by the system task. “Any” means any system process; user processes cannot call the system task directly System Calls in MINIX 3 Figure 2-46. (a) Worst case for reading a block requires seven messages. (b) Best case for reading a block requires four messages. Clock Hardware Figure 4-47. A programmable clock. Clock Software (1) Typical duties of a clock driver. 1. Maintain time of day 2. Prevent processes from running longer than allowed 3. Accounting for CPU usage 4. Handling alarm system call by user processes 5. Providing watchdog timers for parts of system itself 6. Doing profiling, monitoring, and statistics gathering Clock Software (2) Figure 2-48. Three ways to maintain the time of day. Clock Software (3) Figure 2-49. Simulating multiple timers with a single clock. Summary of Clock Services Figure 2-50. The time-related services supported by the clock driver.