Process and Threads

Introduction:

Processes are one of the oldest and most important abstractions that operating systems
provide. They support the ability to have (pseudo) simultaneous operation even when
there is only one CPU available. They turn a single CPU into multiple virtual CPUs.
Without the process abstraction, modern computing could not exist.

PROCESSES
All latest computers frequently do various things at the same time. People used to
working with personal computers may not be fully aware of this fact, so a few examples
may make the point clearer. First examine a Web server. Requests come in from all over
asking for Web pages. When a request comes in, the server checks to see if the page
needed is in the cache. If it is, it is sent back; if it is not, a disk request is started to fetch
it. However, from the CPU's point of view, disk requests take a very long time. While
waiting for the disk request to complete, many more requests may come in. If there are
multiple disks present, some or all of them may be fired off to other disks long before
the first request is satisfied. Obviously some way is required to model and control this
concurrency. Processes (and especially threads) can help here.

Now examine a user PC. When the system is booted, many processes are secretly
started, often unknown to the user. For instance, a process may be started up to wait
for incoming e-mail. Another process may run on behalf of the antivirus program to
check from time to time if any new virus definitions are available. In addition, explicit
user processes may be running, printing files and burning a CDROM, all while the user is
surfing the Web. All this activity has to be managed, and a multiprogramming system
supporting multiple processes comes in very useful here.

In any multiprogramming system, the CPU switches from process to process quickly,
running each for tens or hundreds of milliseconds. While, strictly speaking, at any
instant of time, the CPU is running only one process, in the course of 1 second, it may
work on several of them, giving the false impression of parallelism. Sometimes people

1
 speak of pseudoparallelism in this perspective, to compare it with the true hardware
parallelism of multiprocessor systems (which have two or more CPUs sharing the same
physical memory). Keeping track of multiple, parallel activities is hard for people to do.
Therefore, operating system designers over the years have developed a conceptual
model (sequential processes) that makes parallelism easier to handle.

Process Control Block (PCB)

• A Process Control Block is a data structure maintained by the Operating System

for every process. The PCB is identified by an integer process ID (PID). A PCB
keeps all the information needed to keep track of a process as listed below in the
table −

S.N. Information & Description

1 Process State

The current state of the process i.e., whether it is ready, running, waiting, or whatever.

2 Process privileges

This is required to allow/disallow access to system resources.

3 Process ID

Unique identification for each of the process in the operating system.

4 Pointer

A pointer to parent process.

5 Program Counter

Program Counter is a pointer to the address of the next instruction to be executed for
this process.

2
6 CPU registers

Various CPU registers where process need to be stored for execution for running state.

7 CPU Scheduling Information

Process priority and other scheduling information which is required to schedule the
process.

8 Memory management information

This includes the information of page table, memory limits, Segment table depending
on memory used by the operating system.

9 Accounting information

This includes the amount of CPU used for process execution, time limits, execution ID
etc.

10 IO status information

This includes a list of I/O devices allocated to the process.

• The architecture of a PCB is completely dependent on Operating System and

may contain different information in different operating systems. Here is a
simplified

diagram of a PCB −

3
Process Life Cycle

• When a process executes, it passes through different states. These stages may
differ in different operating systems, and the names of these states are also not
standardized.

• In general, a process can have one of the following five states at a time.

S.N. State & Description

1 Start

This is the initial state when a process is first started/created.

2 Ready

The process is waiting to be assigned to a processor. Ready processes are waiting to

have the processor allocated to them by the operating system so that they can run.
Process may come into this state after Start state or while running it by but interrupted
by the scheduler to assign CPU to some other process.

3 Running

Once the process has been assigned to a processor by the OS scheduler, the process
state is set to running and the processor executes its instructions.

4 Waiting

Process moves into the waiting state if it needs to wait for a resource, such as
waiting for user input, or waiting for a file to become available.

4
5 Terminated or Exit

Once the process finishes its execution, or it is terminated by the operating

system, it is moved to the terminated state where it waits to be removed from
main memory.

When an operating system is booted, normally various processes are created. Some of
these are foreground processes, that is, processes that interact with (human) users and
perform work for them. Others are background processes, which are not associated
with specific users, but instead have some particular function. For instance, one
background process may be designed to accept incoming e-mail, sleeping most of the
day but suddenly springing to life when incoming e-mail arrives. Another background
process may be designed to accept incoming requests for Web pages hosted on that
machine, waking up when a request arrives to service the request. Processes that stay in
the background to handle some activity such as e-mail, Web pages, news, printing, and
so on are called daemons. Large systems generally have dozens of them. In UNIX, the ps
program can be used to list the running processes. In Windows, the task manager can be
used.

Process Creation

Operating systems require some way to make processes. In very simple systems, or in
systems designed for running only a single application (e.g., the controller in a
microwave oven), it may be possible to have all the processes that will ever be needed
be present when the system comes up. In general-purpose systems, however, some
way is required to create and finish processes as required during operation. We will now
look at some of the issues.

There are four principal events that cause processes to be created:

1 . System initialization.
2. Execution of a process creation system call by a running process.
3 . A user request to create a new process.
4 . Initiation of a batch job.

5
Process Termination

After a process has been created, it starts running and performs whatever its job is.
However, nothing lasts forever, not even processes. Sooner or later the new process will
end, generally due to one of the following conditions:

1. Normal exit (voluntary).

2. Error exit (voluntary).
3. Fatal error (involuntary).
4. Killed by another process (involuntary).

Process Hierarchies

In some systems, when a process creates another process, the parent process and child
process continue to be connected in certain ways. The child process can itself create
more processes, forming a process hierarchy. Note that unlike plants and animals that
use sexual reproduction, a process has only one parent (but zero, one, two, or more
children).

In UNIX, a process and all of its children and further descendants together form a
process group. When a user sends a signal from the keyboard, the signal is delivered to
all members of the process group currently connected with the keyboard (generally all
active processes that were created in the current window). Individually, each process
can catch the signal, ignore the signal, or take the default action, which is to be killed by
the signal.

Implementation of Processes

To implement the process model, the operating system maintains a table (an array of
structures), called the process table, with one entry per process. (Some authors call
these entries process control blocks.) This entry includes important information about
the process state, containing 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 to
ready or blocked state so that it can be restarted later as if it had never been stopped.

6
Modeling Multiprogramming

When multiprogramming is used, the CPU utilization can be improved. Crudely put, if
the average process computes only 20% of the time it is sitting in memory, with five
processes in memory at once, the CPU should be busy all the time. This model is
unrealistically hopeful, however, since it tacitly assumes that all five processes will never
be waiting for I/O at the same time.

A better model is to look at CPU usage from a probabilistic viewpoint. Assume 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 I/O (in which case
the CPU will be idle) is pn. The CPU utilization is then given by the formula

CPU utilization = 1 - pn

The following figure shows the CPU utilization as a function of n, which is called the
degree of multiprogramming.

From the figure 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

7
you understand that an interactive process waiting for a user to type something at a
terminal is in I/O wait state, it should be clear that I/O wait times of 80% and more are
not abnormal. But even on servers, processes doing a lot of disk I/O will sometimes have
this percentage or more.

What is Thread?

• A thread is a flow of execution through the process code, with its own program
counter that keeps track of which instruction to execute next, system registers
which hold its current working variables, and a stack which contains the
execution history.

• A thread shares with its peer threads few information like code segment, data
segment and open files. When one thread alters a code segment memory item,
all other threads see that.

Thread Usage

Why would anyone want to have a kind of process within a process? It turns out there
are various reasons for having these miniprocesses, called threads. Let us now look at
some of them. The major reason for having threads is that in many applications,
multiple activities are going on at once. Some of these may block from time to time. By
decomposing such an application into multiple sequential threads that run in quasi-
parallel, the programming model becomes simpler.

In usual operating systems, each process has an address space and a single thread of
control. In reality, that is almost the definition of a process. However, there are often
situations in which it is desirable to have multiple threads of control in the same address
space running in quasi-parallel, as though they were (almost) separate processes
(except for the shared address space). In the following sections we will talk about these
situations and their implications.

8
 Thread Usage

Why would anyone want to have a kind of process within a process? It turns out there
are various reasons for having these miniprocesses, called threads. Let us now look at
some of them. The major reason for having threads is that in many applications,
multiple activities are going on at once. Some of these may block from time to time. By
decomposing such an application into multiple sequential threads that run in quasi-
parallel, the programming model becomes simpler.

We have seen this argument before. It is specifically the argument for having processes.
Instead of thinking about interrupts, timers, and context switches, we can think about
parallel processes. Only now with threads we add a new element: the ability for the
parallel entities to share an address space and all of its data among themselves. This
ability is necessary for certain applications, which is why having multiple processes (with
their separate address spaces) will not work.

A second argument for having threads is that since they are lighter weight than
processes, they are easier (i.e., faster) to create and destroy than processes. In many
systems, creating a thread goes 10-100 times faster than creating a process. When the
number of threads required changes dynamically and rapidly, this property is useful to
have.

A third reason for having threads is also a performance argument. Threads yield no
performance gain when all of them are CPU bound, but when there is substantial
computing and also substantial I/O, having threads allows these activities to overlap,
hence speeding up the application.

Finally, threads are useful on systems with multiple CPUs, where real parallelism is
possible. We will come back to this issue in "MULTIPLE PROCESSOR SYSTEMS".

9
Difference between Process and Thread

1. Threads are easier to create than processes since they don't require a
separate address space.

2. Multithreading requires careful programming since threads share data

structures that should only be modified by one thread at a time. Unlike
threads, processes don't share the same address space.

3. Threads are considered lightweight because they use far less resources
than processes.

4. Processes are independent of each other. Threads, since they share the
same address space are interdependent, so caution must be taken so that
different threads don't step on each other.

5. A process can consist of multiple threads.

S.N. Process Thread

1 Process is heavy weight or Thread is light weight, taking lesser

resource intensive. resources than a process.

2 Process switching needs interaction with Thread switching does not need to
operating system. interact with operating system.

3 In multiple processing environments, All threads can share same set of open files,
each process executes the same code child processes.
but

10
 has its own memory and file resources.

4 If one process is blocked, then no other While one thread is blocked and waiting, a
process can execute until the first second thread in the same task can run.
process is unblocked.

5 Multiple processes without using Multiple threaded processes use fewer

threads use more resources. resources.

6 In multiple processes each process One thread can read, write or change
operates independently of the others. another thread's data.

Advantages of Thread

• Threads minimize the context switching time.

• Use of threads provides concurrency within a process.

• Efficient communication.

• It is more economical to create and context switch threads.

• Threads allow utilization of multiprocessor architectures to a greater scale and

efficiency.

Disadvantages

• In a typical operating system, most system calls are blocking.

• Multithreaded application cannot take advantage of multiprocessing.

Types of Thread

• Threads are implemented in following two ways −

• User threads, are above the kernel and without kernel support. These are the
threads that application programmers use in their programs.

11
 • Kernel threads are supported within the kernel of the OS itself. All modern OSs
support kernel level threads, allowing the kernel to perform multiple
simultaneous tasks and/or to service multiple kernel system calls simultaneously.

User Level Threads

• In this case, the thread management kernel is not aware of the existence of
threads. The thread library contains code for creating and destroying threads, for
passing message and data between threads, for scheduling thread execution and
for saving and restoring thread contexts. The application starts with a single
thread.

Advantages

• Thread switching does not require Kernel mode privileges.

• User level thread can run on any operating system.

• Scheduling can be application specific in the user level thread.

• User level threads are fast to create and manage.

12
Kernel Level Threads

• In this case, thread management is done by the Kernel. There is no thread

management code in the application area. Kernel threads are supported directly
by the operating system. Any application can be programmed to be
multithreaded. All of the threads within an application are supported within a
single process.

• The Kernel maintains context information for the process as a whole and for
individuals threads within the process. Scheduling by the Kernel is done on a
thread basis. The Kernel performs thread creation, scheduling and management
in Kernel space. Kernel threads are generally slower to create and manage than
the user threads.

Advantages

• Kernel can simultaneously schedule multiple threads from the same process
on multiple processes.

• If one thread in a process is blocked, the Kernel can schedule another thread
of the same process.

• Kernel routines themselves can be multithreaded.

Disadvantages

• Kernel threads are generally slower to create and manage than the user threads.

• Transfer of control from one thread to another within the same process
requires a mode switch to the Kernel.

13
Difference between User-Level & Kernel-Level Thread

S.N. User-Level Threads Kernel-Level Thread

1 User-level threads are faster to create Kernel-level threads are slower to create
and manage. and manage.

2 Implementation is by a thread library at Operating system supports creation of

the user level. Kernel threads.

3 User-level thread is generic and can run Kernel-level thread is specific to the
on any operating system. operating system.

4 Multi-threaded applications cannot take Kernel routines themselves can be

advantage of multiprocessing. multithreaded.

One way to organize the Web server is shown in Fig. 2(a). Here one thread, the
dispatcher, reads incoming requests for work from the network. After examining the
request, it chooses an idle (i.e., blocked) worker thread and hands it the request,
possibly by writing a pointer to the message into a special word linked with each thread.
The dispatcher then wakes up the sleeping worker, moving it from blocked state to
ready state.

When the worker wakes up, it checks to see if the request can be satisfied from the Web
page cache, to which all threads have access. If not, it starts a read operation to get the
page from the disk and blocks until the disk operation completes. When the thread

14
blocks on the disk operation, another thread is chosen to run, possibly the dispatcher, in
order to acquire more work, or possibly another worker that is now ready to run.

The Classical Thread Model

What threads add to the process model is to allow multiple executions to take place in
the same process environment, to a large degree independent of one another. Having
multiple threads running in parallel in one process is similar to having multiple processes
running in parallel in one computer. In the former case, the threads share an address
space and other resources. In the latter case, processes share physical memory, disks,
printers, and other resources. Because threads have some of the properties of
processes, they are sometimes called lightweight processes. The term multithreading is
also used to explain the situation of allowing various threads in the same process.

In Fig.1.(a) we see three usual processes. Each process has its own address space and a
single thread of control. On the contrary, in Fig.1.(b) we see a single process with three
threads of control. Though in both cases we have three threads, in Fig.1.(a) each of
them operates in a different address space, whereas in Fig.1.(b) all three of them share
the same address space.

Multithreading Models

• Some operating system provide a combined user level thread and Kernel level
thread facility. Solaris is a good example of this combined approach. In a
combined system, multiple threads within the same application can run in

15
 parallel on multiple processors and a blocking system call need not block the
entire process. Multithreading models are three types

• Many to many relationship.

• Many to one relationship.

• One to one relationship.

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

efficient in nature.

One-To-One Model

• The one-to-one model creates a separate kernel thread to handle each and every
user thread.

16
 • Most implementations of this model place a limit on how many threads can be
created.

• Linux and Windows from 95 to XP implement the one-to-one model for threads.

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 can create any number of the threads.

• Blocking the kernel system calls does not block the entire process.

• Processes can be split across multiple processors.

Thread Libraries

17
 • Thread libraries provides programmers with API for creating and managing of
threads.

• Thread libraries may be implemented either in user space or in kernel space. The
user space involves API functions implemented solely within user space, with no
kernel support. The kernel space involves system calls, and requires a kernel with
thread library support.

18