📠Processes
Last updated
Last updated
In a Uni-Processor System, at any instant, the CPU is only running One process. But, in a Multiprogramming System, the CPU switches from processes quickly, running each for tens or hundreds of milliseconds. The true hardware parallelism is in Multiprocessor systems
A process is an executing program, including the current values of the program counter, registers, and variables. Program: Group of Instructions, passive entity Process: Program Activity, active entity
Code, Data, and Stack
Usually (but not always) has its own address space
Program State
CPU Registers
Program Counter (Current Location in the Code)
Stack Pointer
Only one process can be running in the CPU at any given time
System Initialisation (When the system starts): One or more processes created when the OS starts up Execution of a process creation system call: Something explicitly asks for a new process
System Calls can come from:
User requests to create a new process (system call executed from user shell)
Already running processes
User Programs
System Daemons
Conditions that terminate processes can be
Voluntary
Normal Exit
Error Exit
Involuntary
Fatal Error
Killed by another process
Parent creates a child process
Child processes can create their own children
Forms a hierarchy
UNIX calls this a "Process Group"
If a process exits, its children are "inherited" by the exiting process's parent
However
Windows has no concept of process hierarchy
All processes are created equal
A Process State is defined by the current activity of the process. As a process executes, its state changes.
Only one process can be in the running state at any instant. Many processes can be ready or waiting. Each process is internally represented by the operating system by a Process Control Block (PCB) also called Task Control Block. The PCB contains all information associated with the process, such as:
Process State
Values of Program Counter and other registers
CPU Scheduling Information
Priority, Pointer to Scheduling Queue, etc
Accounting Information
Process ID, CPU and Real-Time Used, Time Limits, etc
I/O Status Information
List of I/O devices allocated, List of Open Files, etc
The process has Two "Layers". The lowest layer of process-structured OS handles interrupts, scheduling. Above that layer are sequential processes - Processes are tracked in the Process Table - Each process has a Process Table Entry
To implement the process model, the operating system maintains a table called a process table, with one entry per process. This entry contains important information about the process' state, including its program counter, stack pointer, memory allocation, the status of its open files, its accounting and scheduling information, and everything else about the process that must be saved when the process is switched from running or ready or blocked state so that it can be restarted later as if it had never been stopped.
Registers
Pointer to Text Segment Info
Root Directory
Program Counter
Pointer to Data Segment Info
Working Directory
Program Status Word
Pointer to Stack Segment Info
File Descriptors
Stack Pointer
User ID
Process State
Group ID
Priority
Scheduling Parameters
Process ID
Parent Process
Process Group
Signals
Time when Process Started
CPU Time Used
Children's CPU Time
Time of Next Alarm
Associated with I/O class is a location (typically at a fixed location near the bottom of the memory) called the interrupt vector. It contains the address of the interrupt service procedure. Suppose that user process 3 is running when a disk interrupt happens. User 3's program counter, program status word, and sometimes one or more registers are pushed onto the current stack by the interrupt hardware. The computer then jumps to the address specified in the interrupt vector. That is all the hardware does. From here on, it is up to the software, in particular, the interrupt service procedure.
All interrupts start by saving the registers, often in the process table entry for the current process. Then the information pushed onto the stack by the interrupt is removed and the stack pointer is set to point to a temporary stack used by the process handler. Actions such as saving the registers and setting the stack pointer can- not even be expressed in high-level languages such as C, so they are performed by a small assembly-language routine, usually the same one for all interrupts since the work of saving the registers is identical, no matter what the cause of the interrupt is.
When this routine is finished, it calls a C procedure to do the rest of the work for this specific interrupt type. (We assume the operating system is written in C, the usual choice for all real operating systems.) When it has done its job, possibly making some process now ready, the scheduler is called to see who to run next. After that, control is passed back to the assembly-language code to load up the registers and memory map for the now-current process and start it running.
It is worth noting that the de- tails vary somewhat from system to system. A process may be interrupted thousands of times during its execution, but the key idea is that after each interrupt the interrupted process returns to precisely the same state it was in before the interrupt occurred.
The diagram below summarises this
When multi-programming is used, CPU utilisation can be improved. Example; If the average process computes only 20% of the time it is sitting in memory, then with five processes in memory at once the CPU should be busy all the time. This is unrealistic but it assumes that all five processes will never be waiting for I/O at the same time.
A better way is to look at CPU usage using probabilities. Suppose that a process spends a fraction p of its time waiting for I/O to complete. With n processes in memory at once, the probability that all n processes are waiting for the I/O (in which the CPU will be IDLE) is p^n. The CPU utilisation is then given by the formula
The diagram below shows the CPU Utilisation as a function of n, which is called the degree of multi-programming.
From the diagram it is clear that if processes spend 80% of their time waiting for I/O, at least 10 processes must be in memory at once to get the CPU waste below 10%. When you realize that an interactive process waiting for a user to type some- thing at a terminal (or click on an icon) is in I/O wait state, it should be clear that I/O wait times of 80% and more are not unusual. But even on servers, processes doing a lot of disk I/O will often have this percentage or more.
Suppose, for example, that a computer has 8 GB of memory, with the operating system and its tables taking up 2 GB and each user program also taking up 2 GB. These sizes allow three user programs to be in memory at once. With an 80% aver- age I/O wait, we have a CPU utilization (ignoring operating system overhead) of 1 − 0. 8^3 or about 49%.
Adding another 8 GB of memory allows the system to go from three-way multi-programming to seven-way multi-programming, thus raising the CPU utilization to 79%. In other words, the additional 8 GB will raise the throughput by 30%. Adding yet another 8 GB would increase CPU utilization only from 79% to 91%, thus raising the throughput by only another 12%. Using this model, the computer’s owner might decide that the first addition was a good investment but that the second was not.
