Carnegie Mellon

Processes
 Carnegie Mellon

Processes

 Definition: A process is an instance of a running program

 Process provides each program with two key abstractions:

▪ Logical control flow
▪ Each program seems to have exclusive use of the CPU

▪ Private virtual address space

▪ Each program seems to have exclusive use of main memory

 How are these Illusions maintained?

▪ Process executions interleaved (multitasking)
▪ Address spaces managed by the virtual memory system
 Carnegie Mellon

Processes
 A process is the OS's abstraction for execution
▪ A process represents a single running application on the system
 Process has three main components:
1. Address space
▪ The memory that the process can access
▪ Consists of various pieces: the program code, static variables, heap, stack, etc.
2. Processor state
▪ The CPU registers associated with the running process
▪ Includes general purpose registers, program counter, stack pointer, etc.
3. OS resources
▪ Various OS states associated with the process
▪ Examples: open files, network sockets, etc.
 Process Address Space
Carnegie Mellon

 Virtual memory of a process

includes
0xFFFFFFFF
▪ the code of the running (Reserved for OS)

program Stack
Stack
▪ the data of the running pointer

program (static variables and Address

Heap
space
heap) Uninitialized vars
(BSS segment)
▪ the execution stack storing local Initialized vars
(data segment)
variables and saved registers for Code Program
0x00000000 (text segment)
each procedure call counter

 This is the process's own view of

the address space
 Process Layout
Carnegie Mellon

STACK ▪ Stack segment is an area of memory allotted

for automatic variables and function
parameters
▪ It also stores a return address while executing
function calls
▪ Stack uses LIFO (Last-In-First-Out)
mechanism for storing local or automatic
variables, function parameters and storing
next address or return address
▪ This segment has a variable size Layout of a process in memory
 Process Layout
Carnegie Mellon

HEAP ▪ It is dynamically allocated memory to a process

during its execution time
▪ Heap segment is area of memory allotted for
dynamic memory storage such as for malloc()
and calloc() calls
▪ This segment size is also variable as per user
allocation
▪ This segment grows from a lower address to a higher
address

Layout of a process in memory

 Process Layout
Carnegie Mellon

DATA ▪ It contains the global and static variables

▪ Data segment is read-write, since the values of
variables could be changed during run time
▪ This segment has a fixed size

TEXT ▪ Text (code) segment is a portion of object file or

program’s virtual address space that consists of
executable instructions
▪ This is usually read-only data segment and has a
fixed size

Layout of a process in memory

 Carnegie Mellon

Execution State (context) of a Process

 Each process has an execution state (context): It indicates what the process is
currently doing
o Running
• Process is currently using the CPU
o Ready
• Currently waiting to be assigned to a CPU
• That is, the process could be running, but another process is using the CPU
o Waiting (or sleeping)
• Process is waiting for an event: Such as completion of an I/O, a timer to go
off, etc.
 As the process executes, it moves between these states
 Carnegie Mellon

Process State (Context) Transitions

▪ New

▪ When a process is created, it exists in secondary memory. Then, the OS picks up

that process from the secondary memory to the main memory to execute it
 Carnegie Mellon

Process State (Context) Transitions

▪ Ready

▪ The ready process exists in the main memory. It waits for the CPU to be
assigned to it. There may be many processes present in the ready state
 Carnegie Mellon

Process State (Context) Transitions

▪ Ready

▪ Any process in a ready state can be taken by the OS and assigned to the CPU
for execution through CPU scheduling algorithms
o If there is only one CPU in a system, then only one process will be in execution at a time
o If there are N number of CPUs in the system, then N number of processes can run simultaneously
 Carnegie Mellon

Process State (Context) Transitions

▪ Request for some I/O device

▪ Interrupt can occur
▪ System Call may invoke

▪ Waiting

▪ From the Running state, a process can go to the waiting state, depending upon
Scheduling algorithm (i.e., time quantum)

▪ When a process requests an I/O, the OS blocks the running process and assigns
the CPU to the next processes
 Carnegie Mellon

Process State (Context) Transitions

▪ Terminated

▪ OS terminates all Processes

▪ When a process finishes its execution, it goes to the termination state

▪ Process Control Block (PCB) is also deleted

 Carnegie Mellon

Process Control Block

 OS maintains a Process Control Block (PCB) for each process
 The PCB is a big data structure with many fields:
o Process ID
o User ID
o Execution state
▪ ready, running, or waiting
o Saved CPU state
▪ CPU registers saved the last time the process was suspended.
o OS resources
▪ Open files, network sockets, etc.
o Memory management info
o Scheduling priority
▪ Give some processes higher priority than others
o Accounting information
▪ Total CPU time, memory usage, etc.
 Carnegie Mellon

Process Scheduling
 The objective of multiprogramming is to
have some process running at all times to
maximize CPU utilization
 The objective of time sharing is to switch a
CPU core among processes so frequently that
users can interact with each program while it is
running.
 To meet these objectives, the process
scheduler selects an available process (possibly
Multicore systems can run multiple
from a set of several available processes) for
processes at one time
program execution on a core
 Each CPU core can run one process at a
time
 Carnegie Mellon

Process Scheduling
 Processes can be described as either I/O bound or CPU bound
o A CPU-bound process, in contrast, generates I/O requests infrequently, using
more of its time doing computations. These tasks involve complex
calculations, data processing, and algorithmic operations that heavily utilize the
CPU
o An I/O-bound process spends more time doing I/O than doing computations.
These operations involve interactions with external resources such as databases,
file systems, network requests, and more. I/O-bound tasks typically involve
reading or writing data from or to external sources
 Carnegie Mellon

Context Switching
 Processes are managed by a shared chunk of OS code called the kernel
▪ Important: the kernel is not a separate process, but rather runs as part of some user
process

 Control flow passes from one process to another via a context switch
 Carnegie Mellon

Context Switching
 Switching the CPU to another process by
saving the current state of a running
process in PCB.

 Loading the saved state from PCB for a

new process is called context switching.

 It is a complementary part of a multitasking

operating system.

 Context switching enables all processes to

share a single CPU to finish their
execution and store the status of the
system’s tasks.
 Carnegie Mellon

Context Switching
 Diagram showing context switch from process to process

▪ When a context switch occurs,

the kernel saves the context of
the old process in its PCB and
loads the saved context of the
new process scheduled to run.
▪ Context switch time is pure overhead
because the system does no useful
work while switching.
Context Switching in Linux
Carnegie Mellon
 State Queues
Carnegie Mellon

 The OS maintains a set of state queues for each process state

o Separate queues for ready and waiting states
o Generally separate queues for each kind of waiting process
• One queue for processes waiting for disk I/O, another for network I/O, etc.
o The queue is generally stored as a linked list
 State Queue Transitions
Carnegie Mellon

 PCBs move between these queues as their state changes

▪ When scheduling a process, pop the head off of the ready queue
▪ When I/O has completed, move PCB from waiting queue to ready queue

Disk I/O completes

 Carnegie Mellon

Concurrent Processes
 Each process is a logical control flow.
 Two processes run concurrently (are concurrent) if their flows overlap in time
 Otherwise, they are sequential
 Examples (running on single core):
o Concurrent: A & B, A & C
o Sequential: B & C
 User View of Concurrent Processes
Carnegie Mellon

 Control flows for concurrent processes are physically disjoint in time

 However, we can think of concurrent processes as running in parallel
with each other
 Operations on Processes
Carnegie Mellon

 The system must provide mechanisms for:

o process creation
o process termination
 Process Creation

o During the course of execution, a process may create several new

processes. The creating process is called a parent process, and the
new processes are called the children of that process

o Each of these new processes may in turn create other processes,

forming a tree of processes
 Creating Processes
Carnegie Mellon

 The system calls for creating processes

o fork() → UNIX

o CreateProcess() → Windows systems

 Parent process creates a new running child process by calling fork
 int fork(void)
o Returns 0 to the child process, child’s PID to parent process
o Child is almost identical to parent:
• Child get an identical (but separate) copy of the parent’s virtual address space.
• Child gets identical copies of the parent’s open file descriptors
• Child has a different PID than the parent
 Creating Processes
Carnegie Mellon

▪ Process creation is achieved through

the fork() system call
▪ The newly created process is called the
child process and the process that
initiated it (or the process when execution
is started) is called the parent process
▪ After the fork() system call, now we have
two processes - parent and child processes
 Creating Processes
Carnegie Mellon

 Generally, the process identified and managed via a process identifier

(pid)

 Resource sharing options

o Parent and children share all resources
o Children share subset of parent’s resources
o Parent and child share no resources
▪ Execution options
o Parent and children execute concurrently
o Parent waits until children terminate
 Creating Processes
Carnegie Mellon

A tree of processes on a typical Linux system

 Carnegie Mellon

Memory concerns
 OS aggressively tries to share memory between processes
o Especially processes that are fork()'d copies of each other
 Copies of a parent process do not actually get a private copy of the
address space...
o ... though that is the illusion that each process gets.
o Instead, they share the same physical memory, until one of them makes a change (COW:
copy-on-write)

 The virtual memory system is behind these tricks

 Carnegie Mellon

Terminating Processes
 A process terminates when it finishes executing its final statement
and asks the operating system to delete it by using the exit() system
call
 At that point, the process may return a status value (typically an
integer) to its waiting parent process (via the wait() system call)
 All the resources of the process including physical and virtual
memory, open files, and I/O buffers are deallocated and reclaimed by
the operating system
 Carnegie Mellon

Terminating Processes
 Process becomes terminated for one of three reasons:
o Receiving a signal whose default action is to terminate (more later)
o Returning from the main routine
o Calling the exit function

 void exit(int status) atexit() registers functions to

o Terminates with an exit status of status be executed upon exit
o Convention: normal return status is 0, nonzero void cleanup(void) {
printf("cleaning up\n");
on error
}
o Another way to explicitly set the exit status is
void fork() {
to return an integer value from the main atexit(cleanup);
fork();
routine
exit(0);
 exit is called once but never returns }
 Carnegie Mellon

Terminating Processes
▪ Parent may terminate the execution of children processes using the
abort() system call. Some reasons for doing so:
o Child has exceeded allocated resources
o Task assigned to child is no longer required
o The parent is exiting and the operating systems does not allow a child to
continue if its parent terminates

▪ If a process terminates, then all its children must also be terminated.

o Cascading termination: All children, grandchildren, etc. are terminated.
o The termination is initiated by the operating system
▪ The parent process may wait for the termination of a child process by
using the wait() system call
 Carnegie Mellon

Process completion status

 int WIFEXITED (int status)

o returns a nonzero value if the child process terminated normally with exit or _exit.
 int WEXITSTATUS (int status)

o If WIFEXITED is true of status, this macro returns the low-order 8 bits of the exit status value from the child process.
 int WIFSIGNALED (int status)

o returns a nonzero value if the child process terminated because it received a signal that was not handled
 int WTERMSIG (int status)

o If WIFSIGNALED is true of status, this macro returns the signal number of the signal that terminated the child process.
 int WCOREDUMP (int status)

o Returns a nonzero value if the child process terminated and produced a core dump.
 int WIFSTOPPED (int status)

o returns a nonzero value if the child process is stopped.

 int WSTOPSIG (int status)

o If WIFSTOPPED is true of status, this macro returns the signal number of the signal that caused the child process to stop.
 Carnegie Mellon

Linux Process Hierarchy

[0]

init [1]

Daemon …
e.g. httpd Login shell Login shell

Child Child Child

Grandchild Grandchild

Note: you can view the hierarchy using the Linux pstree command
 Carnegie Mellon

Other Processes
▪ Orphan Process
o Orphan implies parentless process
o When we run a program or application, the parent process for the application is shell. When we
create a process using fork(), the parent of all the processes is init process (Process ID → 1)
o What happens if the parent process exits before the child process?
o The result is, the child process now becomes the orphan process
▪ Zombie Process
o Zombie process is also known as "dead" process
o Ideally, when a process completes its execution, its entry from the process table should
be removed but this does not happen in the case of zombie a process
o Of course, the zombie process is cleaned up after the parent process becomes ready