***************** *** Lecture 2 *** ***************** Introduction to Processes/Dispaching General Functions of Operating Systems: 1. Coordinator - manage and allocate resources - sharing and protection - scheduling algorithms, deadlock prevention 2. Extended Machine - provides the standard library (stuff everybody needs) - I/O scheduling, file system, virtual memory a) Concurrency - allowing many users to use the same machine at the same time, or allowing one user to run multiple processes at the same time. b) I/O devices - CPU issues commands to the I/O and then moves on to other processes. When the I/O is done, it issues and interrupt to the CPU causing it to stop whatever it's doing regardless of order (asyncronous) and finish the I/O's process. This allows many different devices to operate independently. Also, because CPU and I/O asyncronous, you can never really debug an OS. c) Memory - every process uses memory, OS coordinates the sharing. It also swaps between disk and main memory to simulate limitless memory. d) Files - OS protects each user's files, manages disk allocation e) Networks - manages connections with one's network, internet The OS maintains the illusion that each user has his own processor, main memory and I/O device. This is decomposing a problem rather than making the sharing visible to the users, maintaining the illusion. Definitions: Decomposition - given an hard problem, chop it up into several simpler problems that can be solved seperately. Process - an execution stream in the context of a particular process state. Basically a running piece of code, it's state, and the outside forces that effect the execution of the program. Process State - everything that can effect or be affected by the process. Ex: code, data values, open files, etc. Execution Stream - a sequence of instructions performed by a process. ** A process is the execution of a program, NOT the actual code. ** CODE = SCRIPT; PROCESS = PLAY Uniprogramming Systems: systems that only allow one process at a time. No interrupts are allowed, must wait for one process to finish before starting another one. Difficult to use. Multiprogramming Systems: systems that allow more than one process. Each process things it has its own processor so programmers don't have to worry about the actual sharing. Process Control Block (PCB) - in multiprogramming systems, the PCB keeps track of which programs are running and which ones are not. PCB Needs: - program counter (PC) - pointer to memory (points to the rest of the state that can't be stored in the PCB. - general registers - program to status word [PSW] (the user/system status) - floating point registers - process ID - scheduling information (when was the last interrupt? etc.) - accounting information and other miscellaneous information - pointers to other information; e.g. lists of open files, file descriptions Process Table - collection of all process control blocks. The OS maintains the illusion of seperate processors by switching between many active processes at short intervals. In order for CPU sharing to work, the CPU must make sure that: - each process gets a chance to run - one process doesn't modify another process's state - processes syncronize properly Dispatcher/Scheduler - the part that decides what process will run at any given time. The scheduler will make the decisions and the dispatcher carries them out. Dispatcher Loop: - Run process for some amount of time - Save the process state - Load another process - Loop Issues with scheduling (choosing which process to run next): - only able to schedule jobs that are runnable/ready. If a program is waiting for a resource or user input, it is "blocked". - Which process should it run to get the best performance? - Decision will need to be made quickly or else decision-making time will be longer than actual process-running time. The CPU can only do one thing at a time, if a user process is executing, the dispatcher isn't, so the OS is not in control. For the OS to regain control: - it could wait for the user process to finish - it could issue some kind of interrupt: EIT (execptions, interrupts and traps) Traps - syncronous events in the machine, i.e. page faults, divide by zero, physical memory error, SVC, out of bounds addressing, hardware error, etc. Some traps require that the instruction aborts Interrupts - asyncronous events, usually in the form of I/O interrupts Exception - traps & interrupts External events, like a power failure, will cause a state switch in the OS. User state - can't access real memory, can't read the control registers, can't reset to supervisor state. OS is not in control. User/supervisor states built into the hardware. To regain control of the CPU, use a timer interrupt. Types of Timers: Periodic - issue an interrupt at regular time intervals. Cons: high overhead, low resolution Time of Day [TOD] - interrupt at certain times of the day. Elapsed Time - interupt when timer decrements to zero (most commonly used). How to switch contexts between the user and OS? The problem is that in order to switch contexts, you need to load the PSW and program counter simultaneously. If they're loaded in either order, problems occur. This is built into the hardware. How to Create a New Process: Harder method: from scratch - create an empty call stac - create and initialize the process control block - load code and data into memory - make process known to the dispatcher, put it in the queue Easier method: copy an existing process This method is called forking; used in UNIX. - create a copy of existing processes - copy relevant code and datae into newly forked process, then execute. This method has been improved with vfork; vfork only copies the structure of processes, not the old code and data. Scheduling Allocating Resources: Who gets what resource? What's the most efficient use of the resources? Avoid deadlocking Scheduling: preemptive resources, usually CPU and memory; in what order should they be used? which processes can be suspended with no ill side effects? Blocked -> Run -> Done \ ^ / v | v Submit --> Hold --> Ready Process States: - running - ready, but not currently running - blocked; waiting for something, disk I/O, resource, user input Time Sharing | |-----------------I/O & Page Wait | ^ |------------------------| | | |------------| | | _____ v _____ v _____ |_|_|_ INPUT --> |||| --> |||| --> |||| --> |CPU | --> DONE ----- ----- ----- ------ Hold Runnable In-Memory Over Queue Queue \________________________/ \____________________/ | | SCHEDULER DISPATCHER Hold Queue - holds jobs, usually batch jobs, until the system is ready to provide service Job - all computations oneeded for some process To switch processes, it's more effecient to switch to one that is already in memory because all you need to do is swap registers. Switching to a process in the runnable queue requires more overhead since the data needs to be loaded into memory. Goals for Scheduling: - resource efficiency (keep both the CPU and disk busy) - minimize overhead - minimize response time - maximize throughput - provide a fraction of the machine to specific groups - minimize waiting time for interactive users - avoid starvation (one job never gets run) - minimize variance of response time - meet deadlines - graceful degredation under overload Real goal: keep users happy or minimize complaints. (Remember, not all users are equal. Who pays the bills?) - Typically, the OS tries to minimize the average flow time [f(i)] - time between arrival and completion. - Also minimize the variance of the flow time/service time [f(i)/s(i)], so longer jobs should wait on shorter jobs. Also gives the user a reasonable idea of how long a job will typically take.