Module 2: Process Concept

Module 2
Processes Concept
• A process is a program under execution.
• Its current activity is indicated by PC(Program Counter) and CPU registers.

2.1 Process Concept

Process memory is divided into four sections as shown in the figure below:

• The stack is used to store local variables, function parameters, function return values,
return address etc.
• The heap is used for dynamic memory allocation.
• The data section stores global and static variables.
• The text section comprises the compiled program code.
• Note that, there is a free space between the stack and the heap. When the stack is full,
it grows downwards and when the heap is full, it grows upwards.

Process State
A Process has 5 states. Each process may be in one of the following states –

• New - The process is in the stage of being created.

• Ready - The process has all the resources it needs to run. It is waiting to be assigned to the
processor.
• Running – Instructions are being executed..
• Waiting - The process is waiting for some event to occur. For example the process may be
waiting for keyboard input, disk access request, inter-process messages, a timer to go off,
or a child process to finish.
• Terminated - The process has completed its execution.
 Module 2: Process Concept

Process Control Block

For each process there is a Process Control Block (PCB), which stores the process-specific
information as shown below –

Process State – The state of the process may be new, ready, running, waiting, and so on.

Program counter – The counter indicates the address of the next instruction to be executed for
this process.

CPU registers - The registers vary in number and type, depending on the computer architecture.
They include accumulators, index registers, stack pointers, and general-purpose registers. Along
with the program counter, this state information must be saved when an interrupt occurs, to allow
the process to be continued correctly afterward.
 Module 2: Process Concept

CPU scheduling information- This information includes a process priority, pointers to scheduling
queues, and any other scheduling parameters.

Memory-management information – This include information such as the value of the base and
limit registers, the page tables, or the segment tables.

Accounting information – This information includes the amount of CPU and real time used, time
limits, account numbers, job or process numbers, and so on.

I/O status information – This information includes the list of I/O devices allocated to the process,
a list of open files, and so on.

The PCB simply serves as the repository for any information that may vary from process to process.

The task of switching a CPU from one process to another process is called context switching. Context-
switch times are highly dependent on hardware support (Number of CPU registers).

Whenever an interrupt occurs (hardware or software interrupt), the state of the currently running
process is saved into the PCB and the state of another process is restored from the PCB to the CPU.

Context switch time is an overhead, as the system does not do useful work while switching.

2.2 Process Scheduling

Process Scheduler selects an available process for program execution on the CPU. In a
multiprocessor system - one process will be under execution and the rest of the processes have to
wait until the CPU is free and can be rescheduled.

The main objective of process scheduling is to keep the CPU busy at all times.
 Module 2: Process Concept

Scheduling Queues
• All processes admitted to the system are stored in the job queue.
• Processes in main memory and ready to execute are placed in the ready queue.
• Processes waiting for a device to become available are placed in device queues. There is
generally a separate device queue for each device.

These queues are generally stored as a linked list of PCBs. A queue header will contain two
pointers - the head pointer pointing to the first PCB and the tail pointer pointing to the last PCB
in the list. Each PCB has a pointer field that points to the next process in the queue.
When a process is allocated to the CPU, it executes for a while and eventually quits, interrupted,
or waits for the completion of an I/O request. Since there are many processes in the system, the
disk may be busy with the I/O request of some other process. The process therefore may have to
wait for the disk in the device queue.

A common representation of process scheduling is a queueing diagram. Each rectangular box in the
diagram represents a queue. Two types of queues are present: the ready queue and a set of device queues.
The circles represent the resources that serve the queues, and the arrows indicate the flow of processes in
the system.

A new process is initially put in the ready queue. It waits in the ready queue until it is selected for execution
and is given the CPU. Once the process is allocated the CPU and is executing, one of several events could
occur:

• The process could issue an I/O request, and then be placed in an I/O queue.
 Module 2: Process Concept

• The process could create a new subprocess and wait for its termination.
• The process could be removed forcibly from the CPU, as a result of an interrupt, and be put back
in the ready queue.

In the first two cases, the process eventually switches from the waiting state to the ready state, and is then
put back in the ready queue. A process continues this cycle until it terminates, at which time it is removed
from all queues.

Schedulers

Schedulers are software which selects an available program to be assigned to CPU.

• A long-term scheduler or Job scheduler – selects jobs from the job pool (of secondary
memory, disk) and loads them into the memory. If more processes are submitted, than that
can be executed immediately, such processes will be in secondary memory. It runs
infrequently and can take time to select the next process.

• The short-term scheduler, or CPU Scheduler – selects job from memory and assigns the
CPU to it. It must select the new process for CPU frequently.

• The medium-term scheduler - selects the process in ready queue and reintroduced into
the memory.

Processes can be described as either:

I/O-bound process – spends more time doing I/O than computations,
CPU-bound process – spends more time doing computations and few I/O operations.

An efficient scheduling system will select a good mix of CPU-bound processes and I/O
bound processes.
 Module 2: Process Concept

• If the scheduler selects more I/O bound process, then I/O queue will be full and ready
queue will be empty.
• If the scheduler selects more CPU bound process, then ready queue will be full and I/O
queue will be empty.

Time sharing systems employ a medium-term scheduler. It swaps out the process from ready
queue and swap in the process to ready queue. When system loads get high, this scheduler will
swap one or more processes out of the ready queue for a few seconds, in order to allow smaller
faster jobs to finish up quickly and clear the system.

Advantages of medium-term scheduler –

• To remove process from memory and thus reduce the degree of multiprogramming
(number of processes in memory).
• To make a proper mix of processes(CPU bound and I/O bound )

2.3 Operations on Processes

Process Creation
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. Each of these new processes
may in turn create other processes. Every process has a unique process ID.

On typical Solaris systems, the process at the top of the tree is the ‘sched’ process with
PID of 0. The ‘sched’ process creates several children processes – init, pageout and fsflush.
Pageout and fsflush are responsible for managing memory and file systems. The init process with
a PID of 1, serves as a parent process for all user processes.
A process will need certain resources (CPU time, memory, files, I/O devices) to accomplish its
task. When a process creates a subprocess, the subprocess may be able to obtain its resources in
two ways :
 Module 2: Process Concept

• directly from the operating system

• Subprocess may take the resources of the parent process.
The resource can be taken from parent in two ways –
• The parent may have to partition its resources among its children
• Share the resources among several children.

There are two options for the parent process after creating the child:

• Wait for the child process to terminate and then continue execution. The parent makes a wait
( ) system call.
• Run concurrently with the child, continuing to execute without waiting.

Two possibilities for the address space of the child relative to the parent:

• The child may be an exact duplicate of the parent, sharing the same program and data
segments in memory. Each will have their own PCB, including program counter, registers,
and PID. This is the behaviour of the fork system call in UNIX.

• The child process may have a new program loaded into its address space, with all new code
and data segments. This is the behaviour of the spawn system calls in Windows.
 Module 2: Process Concept

In UNIX OS, a child process can be created by fork() system call. The fork system call, if
successful, returns the PID of the child process to its parents and returns a zero to the child
process. If failure, it returns -1 to the parent. Process IDs of current process or its direct parent
can be accessed using the getpid( ) and getppid( ) system calls respectively.

The parent waits for the child process to complete with the wait() system call. When the
child process completes, the parent process resumes and completes its execution.
 Module 2: Process Concept

In windows the child process is created using the function createprocess( ). The createprocess(
) returns 1, if the child is created and returns 0, if the child is not created.

Process Termination
A process terminates when it finishes executing its last statement and asks the operating system
to delete it, by using the exit( ) system call. All of the resources assigned to the process like
memory, open files, and I/O buffers, are deallocated by the operating system.

A process can cause the termination of another process by using appropriate system call.
The parent process can terminate its child processes by knowing of the PID of the child.

A parent may terminate the execution of children for a variety of reasons, such as:
 Module 2: Process Concept

• The child has exceeded its usage of the resources, it has been allocated.
• The task assigned to the child is no longer required.
• The parent is exiting, and the operating system terminates all the children. This is called
cascading termination.

Note : Processes which are trying to terminate but which cannot because their parent is not
waiting for them are termed zombies. These are eventually inherited by init as orphans and killed
off. (Modern UNIX shells do not produce as many orphans and zombies as older systems used
to. )

2.4 Interprocess Communication

Processes executing may be either co-operative or independent processes.
• Independent Processes – processes that cannot affect other processes or be affected by
other processes executing in the system.
• Cooperating Processes – processes that can affect other processes or be affected by other
processes executing in the system.

Co-operation among processes are allowed for following reasons –

• Information Sharing - There may be several processes which need to access the same file.
So the information must be accessible at the same time to all users.
• Computation speedup - Often a solution to a problem can be solved faster if the problem
can be broken down into sub-tasks, which are solved simultaneously ( particularly when
multiple processors are involved. )
• Modularity - A system can be divided into cooperating modules and executed by sending
information among one another.
• Convenience - Even a single user can work on multiple task by information sharing.

Cooperating processes require some type of inter-process communication. This is allowed by

two models : 1) Shared Memory systems 2)Message Passing systems.

• Shared Memory is faster once it is set up, because no system calls are required and access
occurs at normal memory speeds. Shared memory is generally preferable when large
amounts of information must be shared quickly on the same computer.
 Module 2: Process Concept

• Message Passing requires system calls for every message transfer, and is therefore slower,
but it is simpler to set up and works well across multiple computers. Message passing
is generally preferable when the amount and/or frequency of data transfers is small.

Sl. No. Shared Memory Message passing

1. A region of memory is shared by Message exchange is done among the

communicating processes, into which the processes by using objects.
information is written and read

2. Useful for sending large block of data Useful for sending small data.

3. System call is used only to create shared System call is used during every read
memory and write operation.
4. Message is sent faster, as there are no Message is communicated slowly.
system calls

Shared-Memory Systems

A region of shared-memory is created within the address space of a process, which needs to
communicate. Other processes that needs to communicate uses this shared memory.

The form of data and position of creating shared memory area is decided by the process.
Generally a few messages must be passed back and forth between the cooperating processes first
in order to set up and coordinate the shared memory access. The process should take care that the
two processes will not write the data to the shared memory at the same time.
 Module 2: Process Concept

Producer-Consumer Example Using Shared Memory

This is a classic example, in which one process is producing data and another process is
consuming the data.

The data is passed via an intermediary buffer (shared memory). The producer puts the data
to the buffer and the consumer takes out the data from the buffer. A producer can produce one
item while the consumer is consuming another item. The producer and consumer must be
synchronized, so that the consumer does not try to consume an item that has not yet been
produced. In this situation, the consumer must wait until an item is produced.
There are two types of buffers into which information can be put –
• Unbounded buffer
• Bounded buffer

With Unbounded buffer, there is no limit on the size of the buffer, and so on the data produced
by producer. But the consumer may have to wait for new items.
With bounded-buffer – As the buffer size is fixed. The producer has to wait if the buffer is full
and the consumer has to wait if the buffer is empty.

This example uses shared memory as a circular queue. The in and out are two pointers to the
array. Note in the code below that only the producer changes "in", and only the consumer changes
"out".

• First the following data is set up in the shared memory area:

#define BUFFER_SIZE 10 //buffer

size Typedef struct {
...
} item;
item buffer[
BUFFER_SIZE ]; int in =
0;
int out = 0;

The producer process – Note that the buffer is full when [ (in+1)%BUFFER_SIZE == out ]
Item next Produced;
while( true )
{
 Module 2: Process Concept

/* Produce an item and store it in

nextProduced */

nextProduced = makeNewItem( . . . );

/* Wait for space to become available */

while( ( ( in + 1 ) % BUFFER_SIZE ) == out ) //full
; /* Do nothing */

/* And then, if not full store the

item */ buffer[ in ] = nextProduced;
in = ( in + 1 ) % BUFFER_SIZE;
}

The consumer process – Note that the buffer is empty when [ in == out ]

item nextConsumed;

while( true )
{
/* Wait for an item to become
available */ while( in == out ) //
buffer empty

; /* Do nothing */

/* Get the next available item

*/ nextConsumed = buffer[
out ];
out = ( out + 1 ) % BUFFER_SIZE;
}

Message-Passing Systems

A mechanism to allow process communication without sharing address space. It is used in

distributed systems.

• Message passing systems uses system calls for "send message" and "receive message".
• A communication link must be established between the cooperating processes before
messages can be sent.
• There are three methods of creating the link between the sender and the receiver-
 Module 2: Process Concept

o Direct or indirect communication ( naming )

o Synchronous or asynchronous communication (Synchronization)
o Automatic or explicit buffering.

a. Naming : The processes that wants to communicate should have a way to refer eachother. (
using some identity)

Direct communication the sender and receiver must explicitly know eachothers name. The
syntax for send() and receive() functions are as follows-

send (P, message) – send a message to process P

receive(Q, message) – receive a message from process Q

Properties of communication link :

• A link is established automatically between every pair of processes that wants to
communicate. The processes need to know only each other's identity to communicate.
• A link is associated with exactly one pair of communicating processes
• Between each pair, there exists exactly one link.

Types of addressing in direct communication –

• Symmetric addressing – the above described communication is symmetric

communication. Here both the sender and the receiver processes have to name each
other to communicate.
• Asymmetric addressing – Here only the sender name is mentioned, but the receiving data
can be from any system.

send(P, message) --- Send a message to process P

receive(id, message). Receive a message from any process

Disadvantages of direct communication – any changes in the identifier of a process, may have to change
the identifier in the whole system(sender and receiver), where the messages are sent and received

Indirect communication uses shared mailboxes, or ports.

A mailbox or port is used to send and receive messages. Mailbox is an object into which
 Module 2: Process Concept

messages can be sent and received. It has a unique ID. Using this identifier messages are sent and
received.

Two processes can communicate only if they have a shared

mailbox. The send and receive functions are –
send(A, message) – send a message to mailbox A
receive(A, message) – receive a message from mailbox A

Properties of communication link:

• A link is established between a pair of processes only if they have a shared mailbox. A
link may be associated with more than two processes

• Between each pair of communicating processes, there may be any number of links, each
link is associated with one mailbox.

A mail box can be owned by the operating system. It must take steps to –
⎯ create a new mailbox
⎯ send and receive messages from mailbox
⎯ delete mailboxes.

b) Synchronization
The send and receive messages can be implemented as either blocking or non-blocking.

Blocking (synchronous) send - sending process is blocked (waits) until the

message is received by receiving process or the mailbox.
Non-blocking (asynchronous) send - sends the message and continues (doesnot
wait)

Blocking (synchronous) receive - The receiving process is blocked until a message

is available
Non-blocking (asynchronous) receive - receives the message without block. The
received message may be a valid message or null.

c) Buffering
when messages are passed, a temporary queue is created. Such queue can be of three capacities:

Zero capacity – The buffer size is zero (buffer does not exist). Messages are not stored
in the queue. The senders must block until receivers accept the messages.
Bounded capacity- The queue is of fixed size(n). Senders must block if the queue is full.
 Module 2: Process Concept

After sending ‘n’ bytes the sender is blocked.

Unbounded capacity - The queue is of infinite capacity. The sender never blocks.

2.5 Multi-threaded programming

• A thread is a basic unit of CPU utilization. It consists of a thread ID, program counter, a stack, and
a set of registers.
• Traditional processes have a single thread of control. It is also called as heavyweight process. There
is one program counter, and one sequence of instructions that can be carried out at any given time.
• A multi-threaded application have multiple threads within a single process, each having their own
program counter, stack and set of registers, but sharing common code, data, and certain structures
such as open files. Such process are called as lightweight process.

Motivation
• Threads are very useful in modern programming whenever a process has multiple tasks to perform
independently of the others.
• This is particularly true when one of the tasks may block, and it is desired to allow the other tasks
to proceed without blocking.
• For example in a word processor, a background thread may check spelling and grammar while a
foreground thread processes user input ( keystrokes ), while yet a third thread loads images from
the hard drive, and a fourth does periodic automatic backups of the file being edited.
• In a web server - Multiple threads allow for multiple requests to be served simultaneously. A thread
is created to service each request; meanwhile another thread listens for more client request.
• In a web browser – one thread is used to display the images and another thread is used to retrieve
data from the network.
 Module 2: Process Concept

Benefits
The four major benefits of multi-threading are:
1. Responsiveness - One thread may provide rapid response while other threads are blocked or slowed
down doing intensive calculations. Multi threading allows a program to continue running even if part of it
is blocked or is performing a lengthy operation, thereby increasing responsiveness to the user.
2. Resource sharing - By default threads share common code, data, and other resources, which allows
multiple tasks to be performed simultaneously in a single address space.
3. Economy - Creating and managing threads is much faster than performing the same tasks for processes.
Context switching between threads takes less time.
4. Scalability, i.e. Utilization of multiprocessor architectures – Multithreading can be greatly utilized in a
multiprocessor architecture. A single threaded process can make use of only one CPU, whereas the
execution of a multi- threaded application may be split among the available processors.
Multithreading on a multi-CPU machine increases concurrency. In a single processor architecture, the
CPU generally moves between each thread so quickly as to create an illusion of parallelism, but in reality
only one thread is running at a time.

2.6 Multithreading Models

• There are two types of threads to be managed in a modern system: User threads and kernel threads.
• User threads are the threads that application programmers would put into their programs. They are
supported above the kernel, without kernel support.
• Kernel threads are supported within the kernel of the OS itself. All modern OS support kernel level
threads, allowing the kernel to perform multiple tasks simultaneously.
• In a specific implementation, the user threads must be mapped to kernel threads, using one of the
following models.
 Module 2: Process Concept

a) Many-To-One Model
In the many-to-one model, many user-level threads are all mapped onto a single kernel thread.

• Thread management is handled by the thread library in user space, which is very efficient.
• If a blocking system call is made by one of the threads, then the entire process blocks. Thus
blocking the other user threads from continuing the execution.
• Only one user thread can access the kernel at a time, as there is only one kernel thread. Thus the
threads are unable to run in parallel on multiprocessors.
• Green threads of Solaris and GNU Portable Threads implement the many-to- one model.

b) One-To-One Model
• The one-to-one model creates a separate kernel thread to handle each user thread.
• One-to-one model overcomes the problems listed above involving blocking system calls and the
splitting of processes across multiple CPUs.
• However the overhead of managing the one-to-one model is more significant, involving more
overhead and slowing down the system.
• This model places a limit on the number of threads created.
• Linux and Windows from 95 to XP implement the one-to-one model for threads.

Figure: One to One Model

 Module 2: Process Concept

c) Many-To-Many Model
The many-to-many model multiplexes any number of user threads onto an equal or smaller number of
kernel threads, combining the best features of the one-to-one and many-to-one models.

• Users have no restrictions on the number of threads created.

• Blocking kernel system calls do not block the entire process.
• Processes can be split across multiple processors.
• Individual processes may be allocated variable numbers of kernel threads, depending on the
number of CPUs present and other factors.
• This model is also called as two-tier model.
• It is supported by operating system such as IRIX, HP-UX, and Tru64 UNIX.

Figure : Many to One model Figure : Two Level Model

Module 2: Process Concept