1

Ch # 3 PROCESSES
References:

1. Abraham Silberschatz, Greg Gagne, and Peter Baer Galvin, "Operating System
Concepts, Ninth Edition ", Chapter 3

The Process
A process is basically a program in execution. The execution of a process must progress in a
sequential fashion.

A process is defined as an entity which represents the basic unit of work to be implemented in
the system.
To put it in simple terms, we write our computer programs in a text file and when we execute
this program, it becomes a process which performs all the tasks mentioned in the program.

When a program is loaded into the memory and it becomes a process, it can be divided into four
sections ─ stack, heap, text and data. The following image shows a simplified layout of a
process inside main memory –

Stack: The process Stack contains the temporary data such as method/function parameters,
return address and local variables.

Heap: This is dynamically allocated memory to a process during its run time.
 2

Text: This includes the current activity represented by the value of Program Counter and the
contents of the processor's registers.

Data: This section contains the global and static variables.

Process States
Processes may be in one of 5 states, as shown in following figure.

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

Ready - The process has all the resources available that it needs to run, but the CPU is not
currently working on this process's instructions.

Running - The CPU is working on this process's instructions.

Waiting - The process cannot run at the moment, because it is waiting for some resource to
become available or 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.

The load average reported by the "w" command indicate the average number of processes in the
"Ready" state over the last 1, 5, and 15 minutes, i.e. processes who have everything they need to
run but cannot because the CPU is busy doing something else. Process state diagram is given by:

Process Control Block

 3

A Process Control Block is a data structure maintained by every Operating System in the kernel
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.

Process State - Running, waiting, etc., as discussed above.

Process ID, and parent process ID.

CPU registers and Program Counter - These need to be saved and restored when swapping
processes in and out of the CPU.

CPU-Scheduling information - Such as priority information and pointers to scheduling queues.

Memory-Management information - E.g. page tables or segment tables.

Accounting information - user and kernel CPU time consumed, account numbers, limits, etc.

I/O Status information - Devices allocated, open file tables, etc.

Process Control Block (PCB)

The architecture of a PCB is completely dependent on Operating System and may contain
different information in different operating systems.

Process Scheduling
There are Many Types of Operating Systems which executed the Process either Single or Multiple
Processes are executed at a Single time. And For Executing the Multiple Processes we must have to use
Some Controlling Mechanisms.
 4

As we know that we can perform many Programs at a Tim e on the Computer. But there is a Single CPU.
So for running all the Programs concurrently or simultaneously. Then we use the Scheduling. Processes
are the Small Programs those are executed by the user according to their Request. CPU Executes all the
Process according to Some Rules or Some Schedule. Scheduling ist hat in which each process have Some
Amount of Time of CPU. Scheduling Provides Time of CPU to the Each Process.

Schedulers fell into one of the two general categories :

1. Non pre-emptive scheduling. When the currently executing process gives up the CPU
voluntarily. In this CPU will be automatically free after Executing the Whole Process
Means When the Execution of the Process will Completed then the CPU will be Free.
When two or more Process are given then this will first Complete the Process and after
Completing the First Process, this will Automatically start the Second Process. Non-
Preemptive Scheduling means No scheduling then all the Jobs are Executed One by One.
And in this when the First Job will be Completed, after that second Job will Started.
2. Pre-emptive scheduling. When the operating system decides to favour another process,
pre-empting the currently executing process. Jobs are Executed one by one according to
the Scheduling Techniques, But in this when the Higher Priority will Request for a
Service. To the CPU, then CPU will transfer the Control to the Request Job, Means the
Running job will wait for Some Time.

Process scheduling is an essential part of a Multiprogramming operating systems. Such operating

systems allow more than one process to be loaded into the executable memory at a time and the
loaded process shares the CPU using time multiplexing.

 The two main objectives of the process scheduling system are to keep the CPU busy at
all times and to deliver "acceptable" response times for all programs, particularly for
interactive ones.
 The process scheduler must meet these objectives by implementing suitable policies
(FCFS, RR Scheduling, SJF etc.) for swapping processes in and out of the CPU.

The OS maintains all PCBs in Process Scheduling Queues. The OS maintains a separate queue
for each of the process states and PCBs of all processes in the same execution state are placed in
the same queue. When the state of a process is changed, its PCB is unlinked from its current
queue and moved to its new state queue.

The Operating System maintains the following important process scheduling queues :

Job queue − This queue keeps all the processes in the system.

Ready queue − This queue keeps a set of all processes residing in main memory, ready and
waiting to execute. A new process is always put in this queue.
 5

Device queues − The processes which are blocked due to unavailability of an I/O device
constitute this queue.

Schedulers
Schedulers are special system software which handle process scheduling in various ways. Their
main task is to select the jobs to be submitted into the system and to decide which process to run.
Schedulers are of three types.

1. Long-Term Scheduler

It is also called a job scheduler. A long-term scheduler determines which programs are admitted
to the system for processing. It selects processes from the queue and loads them into memory for
execution. Process loads into the memory for CPU scheduling. On some systems, the long-term
 6

scheduler may not be available or minimal. Time-sharing operating systems have no long term
scheduler.

2. Short Term Scheduler

It is also called as CPU scheduler. Its main objective is to increase system performance in
accordance with the chosen set of criteria. It is the change of ready state to running state of the
process. CPU scheduler selects a process among the processes that are ready to execute and
allocates CPU to one of them. Short-term schedulers, also known as dispatchers, make the
decision of which process to execute next. Short-term schedulers are faster than long-term
schedulers.

3. Medium Term Scheduler

A running process may become suspended if it makes an I/O request. A suspended processes
cannot make any progress towards completion. In this condition, to remove the process from
memory and make space for other processes, the suspended process is moved to the secondary
storage. This process is called swapping, and the process is said to be swapped out or rolled out.

Context Switch
 Whenever an interrupt arrives, the CPU must do a state-save of the currently running
process, then switch into kernel mode to handle the interrupt, and then do a state-restore
of the interrupted process.
 Similarly, a context switch occurs when the time slice for one process has expired and a
new process is to be loaded from the ready queue. This will be instigated by a timer
interrupt, which will then cause the current process's state to be saved and the new
process's state to be restored.
 Saving and restoring states involves saving and restoring all of the registers and program
counter(s), as well as the process control blocks described above.
 Context switching happens VERY VERY frequently, and the overhead of doing the
switching is just lost CPU time, so context switches ( state saves & restores ) need to be
as fast as possible. Some hardware has special provisions for speeding this up, such as a
single machine instruction for saving or restoring all registers at once.
 Some Sun hardware actually has multiple sets of registers, so the context switching can
be speeded up by merely switching which set of registers are currently in use. Obviously
there is a limit as to how many processes can be switched between in this manner,
making it attractive to implement the medium-term scheduler to swap some processes out
as shown in Figure 3.8 above.
 7

Diagram showing CPU switch from process to process

Operations on Processes
1. Process Creation
 Processes may create other processes through appropriate system calls, such as fork or spawn.
The process which does the creating is termed the parent of the other process, which is termed its
child.
 Each process is given an integer identifier, termed its process identifier, or PID. The parent PID (
PPID ) is also stored for each process.
 On typical UNIX systems the process scheduler is termed sched, and is given PID 0. The first
thing it does at system startup time is to launch init, which gives that process PID 1. Init then
launches all system daemons and user logins, and becomes the ultimate parent of all other
 8

processes. Figure 3.9 shows a typical process tree for a Linux system, and other systems will have
similar though not identical trees:

A tree of processes on a typical Linux system

 Depending on system implementation, a child process may receive some amount of shared
resources with its parent. Child processes may or may not be limited to a subset of the resources
originally allocated to the parent, preventing runaway children from consuming all of a certain
system resource.
 There are two options for the parent process after creating the child:
1. Wait for the child process to terminate before proceeding. The parent makes a wait( )
system call, for either a specific child or for any child, which causes the parent process to
block until the wait( ) returns. UNIX shells normally wait for their children to complete
before issuing a new prompt.
2. Run concurrently with the child, continuing to process without waiting. This is the
operation seen when a UNIX shell runs a process as a background task. It is also possible
for the parent to run for a while, and then wait for the child later, which might occur in a
sort of a parallel processing operation. ( E.g. the parent may fork off a number of children
without waiting for any of them, then do a little work of its own, and then wait for the
children. )
 Two possibilities for the address space of the child relative to the parent:
1. 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 behavior of the fork system call in UNIX.
2. The child process may have a new program loaded into its address space, with all new
code and data segments. This is the behavior of the spawn system calls in Windows.
UNIX systems implement this as a second step, using the exec system call.
 9

Process creation using the fork( ) system call

Process Termination
 Processes may request their own termination by making the exit( ) system call, typically returning an
int. This int is passed along to the parent if it is doing a wait( ), and is typically zero on successful
completion and some non-zero code in the event of problems.
 Processes may also be terminated by the system for a variety of reasons, including:
a. The inability of the system to deliver necessary system resources.
b. In response to a KILL command, or other un handled process interrupt.
c. A parent may kill its children if the task assigned to them is no longer needed.
d. If the parent exits, the system may or may not allow the child to continue without a
parent. ( On UNIX systems, orphaned processes are generally inherited by init, which
then proceeds to kill them. The UNIX nohup command allows a child to continue
executing after its parent has exited. )
 When a process terminates, all of its system resources are freed up, open files flushed and closed,
etc. The process termination status and execution times are returned to the parent if the parent is
waiting for the child to terminate, or eventually returned to init if the process becomes an orphan. (
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. Note that
modern UNIX shells do not produce as many orphans and zombies as older systems used to. )

Interprocess Communication
 Independent Processes operating concurrently on a systems are those that can neither affect
other processes or be affected by other processes.
 Cooperating Processes are those that can affect or be affected by other processes. There are
several reasons why cooperating processes are allowed:
o Information Sharing - There may be several processes which need access to the
same file for example. ( e.g. pipelines. )
o Computation speedup - Often a solution to a problem can be solved faster if the
problem can be broken down into sub-tasks to be solved simultaneously (
particularly when multiple processors are involved. )
o Modularity - The most efficient architecture may be to break a system down into
cooperating modules. ( E.g. databases with a client-server architecture. )
o Convenience - Even a single user may be multi-tasking, such as editing,
compiling, printing, and running the same code in different windows.
 10

 Cooperating processes require some type of inter-process communication, which is most

commonly one of two types: Shared Memory systems or Message Passing systems. Figure
3.13 illustrates the difference between the two systems:

Communications models: (a) Message passing. (b) Shared memory

 Shared Memory is faster once it is set up, because no system calls are required and access
occurs at normal memory speeds. However it is more complicated to set up, and doesn't work
as well across multiple computers. Shared memory is generally preferable when large
amounts of information must be shared quickly on the same computer.
 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, or when
multiple computers are involved.
1. Shared-Memory Systems
 In general the memory to be shared in a shared-memory system is initially within the
address space of a particular process, which needs to make system calls in order to make
that memory publicly available to one or more other processes.
 Other processes which wish to use the shared memory must then make their own system
calls to attach the shared memory area onto their address space.
 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.

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. ( In this example in the order in which it is produced, although that
could vary. )
 11

 The data is passed via an intermediary buffer, which may be either unbounded or bounded.
With a bounded buffer the producer may have to wait until there is space available in the
buffer, but with an unbounded buffer the producer will never need to wait. The consumer
may need to wait in either case until there is data available.

2. Message-Passing Systems
 Message passing systems must support at a minimum 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 key issues to be resolved in message passing systems as further explored in
the next three subsections:
o Direct or indirect communication ( naming )
o Synchronous or asynchronous communication
o Automatic or explicit buffering.

1. Naming

 With direct communication the sender must know the name of the receiver to which it
wishes to send a message.
o There is a one-to-one link between every sender-receiver pair.
o For symmetric communication, the receiver must also know the specific name
of the sender from which it wishes to receive messages.
o For asymmetric communications, this is not necessary.
 Indirect communication uses shared mailboxes, or ports.
o Multiple processes can share the same mailbox or boxes.
o Only one process can read any given message in a mailbox. Initially the
process that creates the mailbox is the owner, and is the only one allowed
to read mail in the mailbox, although this privilege may be transferred.
o ( Of course the process that reads the message can immediately turn
around and place an identical message back in the box for someone else to
read, but that may put it at the back end of a queue of messages. )
o The OS must provide system calls to create and delete mailboxes, and to
send and receive messages to/from mailboxes.

2. Synchronization

Either the sending or receiving of messages ( or neither or both ) may be either blocking
or non-blocking.

3. Buffering
 12

Messages are passed via queues, which may have one of three capacity configurations:

1. Zero capacity - Messages cannot be stored in the queue, so senders must block until
receivers accept the messages.
2. Bounded capacity- There is a certain pre-determined finite capacity in the queue.
Senders must block if the queue is full, until space becomes available in the queue, but
may be either blocking or non-blocking otherwise.
3. Unbounded capacity - The queue has a theoretical infinite capacity, so senders are never
forced to block.