Operating Systems Design and Implementation Chapter 02 (version January 30, 2008 ) Melanie Rieback Vrije Universiteit Amsterdam, Faculty of Sciences Dept. Computer Science Room R4.23. Tel: (020) 598 7874 E-mail: melanie@cs.vu.nl, URL: www.cs.vu.nl/ ∼ melanie/ 01 Introduction 02 Processes 03 Input/Output 04 Memory Management 05 File Systems 00 – 1 /
Processes • Processes, introduction • Interprocess communication • IPC problems • Scheduling • Processes in MINIX • Implementation in MINIX 02 – 1 Processes/
Processes Primitive model: a process represents a user or ap- plication and executes a program on behalf of its owner. Data involved in this processing is retrieved from and stored on files. Data in files persist over processes. A process is an invention by an operating system: it is used as a placeholder for executing programs so that we can keep a precise account of how program exe- cution is affecting the use of hardware and software resources. process = program in execution 02 – 2 Processes/2.1 Introduction to Processes
Concurrent Processes Important: processes are, in principle, mutually inde- pendent. This implies that the CPU can be allocated in turn to different processes: One program counter Four program counters Process� A switch D� Process B C� B� A B C D C A D Time (a) (b) (c) • You don’t know when the operating system de- cides to allocate the CPU to a next process. • Processes are independent: they need explicit means to communicate with each other. • Always remember: a process executes a program; a process is not the same as a program. 02 – 3 Processes/2.1 Introduction to Processes
Process Hierarchies Basic problem: How do you actually create processes? In many systems, the operating system creates just one initial process. Solution: offer primitives that allow a process to cre- ate another process ⇒ leads to a hierarchy of pro- cesses: A B C D E F Question: What would happen when a parent pro- cess dies? 02 – 4 Processes/2.1 Introduction to Processes
Process States Basic idea: If the operating system is to allocate re- sources such as the CPU to processes, it will have to select suitable processes for allocation ⇒ we need to keep track of the state of a process: Running 1. Process blocks for input� 2. Scheduler picks another process� 1 3 2 3. Scheduler picks this process� 4. Input becomes available Blocked Ready 4 • Running : the process is currently executed by the CPU • Blocked : the process is waiting for a resource to come available • Ready : the process is ready to be selected The scheduler takes decisions on (de)allocation of the CPU (transitions 2 & 3). Question: How can transitions 1 & 4 take place? 02 – 5 Processes/2.1 Introduction to Processes
Scheduler vs Processes Note: it is the scheduler who decides to (de)allocate the CPU. This leads to a simple process organization: Processes 0 1 n – 2 n – 1 Scheduler Question: Does this organization have anything to do with the hierarchical organization of processes? 02 – 6 Processes/2.1 Introduction to Processes
Process Implementation To implement processes, the OS keeps track of the process’ state, values of registers, memory usage, etc. In MINIX: Kernel Process management File management Registers Ptr to text segment UMASK mask Program counter Ptr to data segment Root directory Program status word Ptr to bss segment Working directory Stack pointer Exit status File descriptors Process state Signal status Real UID Current scheduling priority Process ID Effective UID Maximum scheduling priority Parent process Real GID Scheduling ticks left Process group Effective GID Quantum size Children’s CPU time Controlling TTY CPU time used Real UID Save area for read/write Message queue ptrs Effective UID System call parameters Pending signal bits Real GID Various flag bits Various flag bits Effective GID Process name File info for sharing text Bitmaps for signals Various flag bits Process name Question: Why do we see redundancy in maintaining states ? 02 – 7 Processes/2.1 Introduction to Processes
Interrupt Handling Basic idea: To deallocate the CPU in favor of the scheduler, we use hardware support – whenever the hardware generates an interrupt (e.g., on account of a timer), the scheduler “automagically” gets control. • Associated with each I/O device is a memory lo- cation where execution continues when that de- vice generates an interrupt ( interrupt vector ). • The interrupt vector contains the start address of an operating-system provided procedure ( inter- rupt handler ). Execution continues with that pro- cedure. 02 – 8 Processes/2.1 Introduction to Processes
Interrupt Handling & Scheduling 1. Hardware stacks program counter, etc. 2. Hardware loads new program counter from interrupt vector 3. Assembly language procedure saves registers 4. Assembly language procedure sets up a new stack 5. C interrupt service constructs and sends message 6. Message-passing code marks waiting message recipient ready 7. Scheduler decides which process is to run next 8. C procedure returns to the assembly code 9. Assembly language procedure starts up new current process Note: Every time an interrupt occurs, the scheduler will eventually get control. It acts as the big mediator. A process can normally not give the CPU to another process without going through the scheduler. 02 – 9 Processes/2.1 Introduction to Processes
Threads Idea: Sometimes you want something as a process in order to structure your application, but you don’t want the overhead that goes with it ⇒ make use of threads. Basic idea: Threads also share resources, but only within the same process ⇒ resource management is completely left outside the control of the operating sys- tem. 02 – 10 Processes/2.1 Introduction to Processes
Threads: Minimal Support Important: threads fall under the regime of a single process, and thus reside in the same address space ⇒ all information exchange is through data shared be- tween the threads. • Each thread has its own stack, processor context, and state; • Threads should synchronize through simple prim- itives (semaphores, monitors); • Each thread may call upon any service provided by the operating system; it does so on behalf of the process to which it belongs. Computer Computer Program� Thread Process counter (a) (b) Question: What’s so light-weight about all this? Where do processes and threads really differ? 02 – 11 Processes/2.1 Introduction to Processes
Threads – Some Problems • Does the OS keep an administration of threads ( kernel threads ), or not ( user threads )? Ques- tion: What happens if a user-space thread does a blocking system call? • What to do when you clone a process: does the new process get all the threads as well? What about threads currently blocking on a system call? • When the OS sends a signal, how can you relate that signal to a thread? Should you relate it to a thread? Conclusion: Designing threads is maybe just a bit more tedious than you would expect at first thought. 02 – 12 Processes/2.1 Introduction to Processes
Interprocess Communication The essence: Processes need to communicate with each other: • Data needs to be exchanged between processes • We have to synchronize processes to avoid they get in each other’s way • We need to synchronize processes on account of dependencies 02 – 13 Processes/2.2 Interprocess Communication
Race Conditions Spooler� directory 4� abc� out = 4 5� prog. c� Process A 6� prog. n 7� in = 7 � Process B • Process A reads in = 7 , and decides to append its file at that position • Process A is suspended by the OS (because its time slot expired) • Process B also reads in = 7 , puts its file at that position. It then sets in to 8 and eventually gets suspended • Process A writes its file to position 7 Problem: reading and updating in should be an atomic action . If it’s not, processes can race each other and come to the wrong conclusions. 02 – 14 Processes/2.2 Interprocess Communication
Mutual Exclusion Critical region: A piece of shared memory (like a common variable) for which we have: 1: No two process may be simultaneously in their critical regions 2: No assumptions may be made about speeds or number of CPUs 3: No process running outside its critical region may block other processes 4: No process should have to wait forever to enter its critical region (Non)solutions: • Disable interrupts: simply prevent that the CPU can be re-allocated. Pretty blunt. Works for single- CPU systems only. • Lock variables: Same as with the spooler vari- able in : you’re just too late to give the variable its new value 02 – 15 Processes/2.2 Interprocess Communication
Mutual Exclusion Strict Alteration while(TRUE) { while(TRUE) { while(turn != 0); while(turn != 1); critical_region(); critical_region(); turn = 1; turn = 0; noncritical_region(); noncritical_region(); } } Question: Which assumption is implicitly being made? Note: This is again a nonsolution: it violates the con- dition that processes may not block each other. 02 – 16 Processes/2.2 Interprocess Communication
Recommend
More recommend
