10 The operating system main responsibility is to control the execution of processes. In other words, it is suppose to determine the interleaving pattern for execution and allocating resources to the process. A simple model with two states per process can be used to describe the behavior of a process. The state transition diagram of a process is presented in this slide. When the OS creates a new process, it enters it into the Not Running state; after that, the process exists, is known to the OS and waits for the opportunity to run From time to time, the currently running process will be interrupted and the dispatcher process will select a new process to run; The former process is brought into Not Running state, and the new process will be moved to Running state.
11 From the two states process model, we already start to appreciate some of design elements of an Operating System. Each of the processes needs to be represented in some way, so the operating system can keep track of it. There must be some information rating to each process, i.e. current state and location in memory. Processes that are not running must be kept in some sort of queue, waiting their turn to execute.
12 Regardless of the used model, the life of a process is bounded by its creation and its termination
15 If all processes were always ready to execute, than the queuing discipline suggested so far would be effective. The queue was first in first out and the processor operates in round robin fashion on the available processes (each process in the queue it is given an certain amount of time, in turn, to execute and then returned to the queue). The two state model is in fact not accurate, because some of the processes in the Not Running state are ready to execute, while some others are suspended, waiting for the completion of an I/O operation.
16 The process manager uses the state diagram to determine what type of service to provide to the process. If process is in ready state then it is competing for the CPU time; there is no other transition from this state but to be scheduled (or dispatched) and become active or running If process is active or running , the process can: Complete its execution, transitioning in exit state May request an I/O operation: If the requested resource is available immediately, then the execution can continue If the requested resource is not immediate, the process manager notifies the resource manager that the process requires units of its resource; the process goes in suspended or blocked mode waiting for an resource allocation event; the scheduler/dispatcher is invoked to chose the next process to become active from the ready process list The process may be interrupted due to some external event (i.e. exceeded the allocated CPU time) and is taken into ready state If the process is in blocked state, the process can move into ready state when it is being allocated the requested resource or when an external event occurs; it then competes again for the processor
18 When an event appears, the operating system has to scan the whole blocked queue and figure out which process is waiting on that event … this can be very inefficient in large operating systems (where the blocked queue can have a few thousands entries)
22 Memory tables – used to keep track of both main (real) and secondary (virtual) memory. Some of main memory is reserved for use by the operating system; the remainder is available to the processes. I/O tables are used by the operating system to manage the I/O devices. File tables are used to manage the files and accesses to the files. Primary process table is used to keep one entry per each process in the operating system. Each entry contains at least one pointer to a process image. The Process Image contains data, code, stack and process control block (attributes and information about process) associated with a process. Those tables are linked (even if not shown) or cross referenced. Memory, Files and I/O are managed in behalf of processes, so there must be some reference to those resources in the processes tables (direct or indirect references). Those tables are created whenever the operating system is initialized (so the operating system must know about the physical environment it operates in, i.e. how much physical RAM is available, etc…).
33 In this slide, each process appears as contiguous range of addresses. In an actual implementation, this may not be the case. It will depend on the memory management scheme and the way in which control structures are organized by the operating system.
35 Hardware support: Multiple registers set, one per mode, no need for save / restore of user registers Existence of an address space that can be automatically mapped in protected mode and not accessible in user mode
44 Unix employs two RUNNING states to indicate whether the process is executing in user mode or kernel mode.
45 Preempted and Ready to run, in memory are nearly identical A process may be preempted for a higher-priority process at the end of a system call. Preemption can only occur when a process is about to move from kernel mode to user mode. While a process is running in kernel mode, it may not be preempted. This makes UNIX unsuitable for real time processing. Zombie – Saves information to be passed to the parent of this process. Two processes are unique in UNIX: Process 0 – Swapper , created at boot time Process 1 – Init , creates other processes and it is spawned by process 0.
49 Process table entry and the U area are detailed next.
50 This process table is maintained by the operating system, with one entry per process. It contains process control information that is accessible to the kernel at all times; hence in a virtual memory system, all process table entries are maintained in the main memory (to be fast accessible).
51 The user area contains additional control information that is needed by the kernel when it is executing in the context of this process. The distinction between the process table entry and the U area reflects the fact that UNIX kernel always executes in the context of some process. Much of the time, the kernel will deal with concerns of that process. However, some of the time, such as when scheduling is performed, it will need access to information about other processes.
52 All of this happens in the parent process, in kernel mode. When the kernel has completed those functions, it will one of the following things: Will return to user mode in the parent process, at the point of fork() Transfer control to the child process. The child code will start executing at the return point from the fork call Transfer control to another process. Both parent and the child are left in the Ready to Run stte.
53 Characteristics of Processes Implemented as objects May contain one or more threads Both processes and threads have built-in synchronization capabilities
54 Each process is represented by an object (in the slide). Each process is defined by a number of attributes and encapsulates a number of actions (services) that it may perform. A process will perform a service by receiving a message (the only way of invoking such a service is by means of messages). Each process must contain at least one thread. The thread object structure is represented in the slide. Multithreading Threads in the same process can execute concurrently Symmetric MultiProcessor Support Any thread (including kernel threads) can run on any processor Soft affinity – Try to reschedule a thread on the same processor Hard affinity – Restrict a thread to certain processors
55 Thread States: Ready – Able to run Standby – Scheduled to run Running Waiting – Blocked or suspended Transition – Not blocked, but can’t run (paged out of memory) Terminated Support for O.S. Subsystem Process creation Begins with request from application Goes to protected subsystem Passed to executive, returns handle Win32 use handle to create thread Return process/thread information Win2000 - client requests a new thread Thread inherits limits, etc. from parent
57 Running – either executing or ready to execute (made out of two states) Interruptible – this is a blocked state, in which the process is waiting for an event, such as the end of an I/O operation, the availability of a resource or a signal from another process Uninterruptible – this is another blocked state. The difference between this and the previous is that here a process is waiting directly on hardware conditions and therefore will not accept any signals. Stopped – the process has been halted and can be resumed only by positive action from another process (i.e. a process that is being debugged can be stopped by another process- the debugger). Zombie – process has been terminated but still must have its task structure in the task list (process table).