Download Module 4: Processes

Chapter 3: Processes
modified by your instructor
Chapter 3: Processes
 Process Concept
 Process Scheduling
 Operations on Processes
 Cooperating Processes
 Interprocess Communication
 Communication in Client-Server Systems
 This is a very important chapter now that we have completed the
introductory materials.
 This will require two to three lectures.
Operating System Concepts
3.2
Silberschatz, Galvin and Gagne ©2005
Introductory Remarks –
Quick Review Concepts Slide
 We speak of programs and processes.
 It is important to distinguish between the two.
 A process is a program in execution; a unit of work.
 Programs are files stored somewhere – static and passive
 A process is executing and needs resources from the computing system such as

CPU cycles

Memory

Files

I/O devices.
 But the operating system is responsible for executing processes and all management
of overall resources and those related to processes:

Creation / deletion of user and system processes (user code, system code).

Process scheduling

Synchronization of processes, communication among processes, and the
handling of deadlock conditions that can occur among processes.
Operating System Concepts
3.3
Silberschatz, Galvin and Gagne ©2005
Process Concept
 An operating system executes a variety of programs:

Batch system – jobs
 These

usually run from beginning to end
Time-shared systems – user programs or tasks
 Especially
interactive tasking…
 Textbook uses terms job and process almost
interchangeably (for some systems, this is okay, but not all!)
 Process – a program in execution
 A process includes:

program counter (contained in a CPU register)

Current register settings

Stack (will see its use ahead)

data section – global variables
Operating System Concepts
3.4
Silberschatz, Galvin and Gagne ©2005
Process in Memory
Text – the object code instructions
Program Counter – address of the next instruction
to be fetched from memory, brought into
the CPU, decoded, and executed
Register settings – current values of working registers
Stack – temporary area for program parameters,
return addresses, stack frames (used for
recursion) local variables (specific method)
Data – global variables; other data; buffers
Heap – (optional) hunk of memory that may be made
available for dynamic storage allocation like
for creation of objects and more
We usually refer to all this as a
processes ‘address space.’
Operating System Concepts
3.5
Silberschatz, Galvin and Gagne ©2005
Process State
 As any process executes, it changes state.
 All processes have ‘state.’

new: The process is being created

running: Instructions are being executed

waiting: The process is waiting for some event
to occur

ready: The process is waiting to be assigned to
a process

terminated: The process has finished execution
 Even when a process is running, it’s ‘internal’ state
is changing! (values of its variables, etc.)
Operating System Concepts
3.6
Silberschatz, Galvin and Gagne ©2005
Diagram of Process State
Discuss states and
their transitions
Important to note that at any given instant in time, a CPU can only be executing
a single instruction from a user or operating system process.
Other processes are in other ‘states’ like waiting or ready, or …
Operating System Concepts
3.7
Silberschatz, Galvin and Gagne ©2005
Process Control Block (PCB)
 Every process has a PCB – an abstraction of the process itself.
 Some vendors call PCBs task control blocks (IBM, for example)
 The PCB is a data structure used to manage the process.
 It contains: (shown on next slide) everything needed to ‘represent’ the





process.
Process state – ready, waiting, running, etc.
Program counter – address of next instruction
CPU registers – instruction registers, stack pointers, index registers,
condition-code and/or flag registers….
CPU scheduling information – scheduling priorities; specific ‘queues’
Memory-management information
Base / limit registers; page tables; segment tables –
 these depend upon the memory management scheme used

 Accounting information – amount of CPU time; memory used, account
numbers, time limits, … other resource computations used…
 I/O status information – list of I/O devices allocated to the process; list
of open files, their status, etc.
Operating System Concepts
3.8
Silberschatz, Galvin and Gagne ©2005
Process Control Block (PCB)
When a process changes state, say from
Running to Wait, the values / contents of the
CPU’s registers, instruction counter, etc. are
copied into this abstraction of the process to
provide for resumption later.
All processes have a PCB to represent
them and the resources, constraints,
temporary values, etc. associated with
the process they represent.
Used to manage the process – resumption
of processing, protection of areas of memory,
accounting info and much more.
Operating System Concepts
3.9
Silberschatz, Galvin and Gagne ©2005
CPU Switch From Process to Process
Originating outside or
within the process.
Note:
Discuss
“Context
Switching!”
Or some other
Ready process!
Operating System Concepts
3.10
Silberschatz, Galvin and Gagne ©2005
Process Scheduling Queues
 Remember: goal of what we call multiprogramming is
to have some process running all the time to maximize
CPU utilization;
 Goal of time sharing is to switch the context from one
process to another so users can interact with each
program while it is running.
  With a single processor system, only one program
can be ‘running’ at any instant in time.
 Thus we have a real need of very robust ‘scheduling.’
 This can be a very complex undertaking with several
queues and algorithms for determining the ‘best’ CPU
utilization while providing required services.
Galvin and Gagne ©2005
 We call this the ‘mix’ and3.11refer to this as Silberschatz,
CPU loading.
Operating System Concepts
Process Scheduling Queues
 Job queue – set of all processes in the system

These may likely not be ‘ready’ for execution, but they are in the system and
desire to be executed. (have not been made ‘ready’)
 Ready queue – set of all processes residing in main memory, ready and waiting
to execute; that is, ready for CPU dispatching.

The ‘Ready Queue’ is often implemented as a linked list

Unfortunately, there may be a number of Ready queues (later!)

The Ready-queue header contains a pointer to the first PCB in ready queue.

Other PCBs are linked via a singly-linked forward pointer part of each PCB.
 Device queues – set of processes waiting for an I/O device, as you might expect.

Two processes requesting access to the same device will require queueing.
 Different data structure may be used to manage different queues; Different
searching techniques may be used within different queues to obtain the ‘next’
process. Regular queues, priority queues, etc. may be used ‘here and there.’ 
 Important to note: Processes migrate among the various queues
Operating System Concepts
3.12
Silberschatz, Galvin and Gagne ©2005
Observe the Structure of the PCB in Linux
 Of course, Linux (written in C) uses structures. E.g. struct data.
 A process’s parent is the process that created it (for multi threading).
 A few of the fields are:

pid_t pid;
// a unique process identifier (usually integer)

long state;
// state of the process

unsigned int

struct files_struct *files
// list of open files (string data)

struct mm_struct *mm
// address space of the process
time_slide
// scheduling info

State of the process is in ‘state’ (captured in this PCB)

In Linux kernel, all active processes are presented using a
doubly-linked list of task_struct and the kernel maintains a pointer
called “current” to the process currently executing.

Good figure in your textbook. Pretty straightforward.
Operating System Concepts
3.13
Silberschatz, Galvin and Gagne ©2005
Ready Queue And Various I/O Device Queues
Remember from your
data structures course
that regular queues
have items (places in
an array, nodes, etc.
(PCBs here) inserted
into the ‘tail’ and items
(PCBs here too)
removed (or accessed)
from the ‘head’ of the
queue.
These ‘headers’ are
permanent. But PCBs
are created and destroyed
as needed.
A regular queue, then,
has at least these two
pointers: one to the
head, and one to the
tail.
Operating System Concepts
3.14
Silberschatz, Galvin and Gagne ©2005
Representation of Process Scheduling
Brief look at process scheduling
There are two queues here:
a ‘ready queue’ and
a ‘device queue.’
When a new process
is made ‘ready’ it is put
into a ready queue
until it is dispatched!
Once dispatched, process
may continue until
- process requests an I/O
- process creates a new
sub-process and will now
await sub-process termination, or
- process could be forcibly removed from CPU via an interrupt and be placed back in
ready queue.
Operating System Concepts
3.15
Silberschatz, Galvin and Gagne ©2005
Schedulers
 Clearly, a process will migrate among different queues as it continues
along a path of execution until process terminates.
 But he actual selection of which process to execute is carried out by a
scheduling algorithm.
 Long-term scheduler (or job scheduler) – selects which processes should
be brought into the ready queue from outside of what is being executed…
 Particularly useful for batch jobs.
 Usually these are spooled onto disk …..
Not executed too frequently – maybe even minutes between creation of a
new process
 The job scheduler controls the degree of multiprogramming, a.k.a. the
number of processes in memory.
 Ideally, the rate of process termination influences the rate at which the job
scheduler schedules a new job for execution – assuming the job mix is in a
stable operation.
 (All kinds of parameters in the selection process – ahead)
Again, we are after a good ‘mix’ of processes – depending on their
‘characteristics’ to provide for excellent service to users and high CPU
utilization and other system resources.

Operating System Concepts
3.16
Silberschatz, Galvin and Gagne ©2005
Scheduler
 Short-term scheduler (or CPU scheduler) – selects which
process should be executed next and allocates CPU

Processes ‘provided’ to the CPU scheduler via queueing are
frequently executed only for a very short time – until they
request an I/O, cause a trap, fork a process, etc.

But then these are rapidly placed back into the ‘ready queue’
(CPU queue).
 Great care must be taken by the job scheduler in selecting
processes ‘into the mix.’
 The differences between I/O bound jobs and CPU-bound jobs is
incredibly important!
 Much more directly ahead on this…
Operating System Concepts
3.17
Silberschatz, Galvin and Gagne ©2005
Schedulers (Cont.)


Processes can be described as either:
 I/O-bound process – spends much more time doing I/O than
computations, many short CPU bursts.
 This means that these jobs may spend a lot of time in a wait queue before
they become ‘ready’ again (once the I/O request has been accommodated.
 Too many of these in the mix and the CPU becomes idle. This is bad!
 Ready queue may become empty, and the short-term scheduler (CPU
scheduler) may have little to do.
 These tend to be business-oriented, file processing, data base jobs.
CPU-bound process – spend more time doing computations; few ‘long’ CPU
bursts
 If the mix contains too many computationally-oriented jobs, the I/O waiting
queue may be empty; I/O devices unused, and system load unbalanced.
This too is bad.
 These tend to be more scientific or engineering type jobs where there may
be a lot of computations rather than lots of input/output.
 Systems providing the best overall performance must have a
good mix of both I/O bound jobs and CPU-bound jobs in a
general purpose processing environment.
Operating System Concepts
3.18
Silberschatz, Galvin and Gagne ©2005
More on Schedulers
 Unix and Microsoft Windows do not have a job scheduler.
 Put all input processes into memory for the CPU scheduler.
 Stability depends on the physical limitations of the computing
system (like number of terminals, devices, etc.).
 System can come to a grinding halt too.
 Other operating systems may use a medium-term scheduler that
may be used to remove processes from memory (and thus for
active contention for the CPU) and thus reduce the degree of
multiprogramming, but lighten the burden on the operating system
and improve throughput should throughput become an issue….
 This scheme is called swapping, and the swapped process will be
later ‘swapped’ back in.
 Discussed in later chapters.
Operating System Concepts
3.19
Silberschatz, Galvin and Gagne ©2005
Context Switch

When CPU switches to another process, the system must save the state of the old
process and load the saved state for the new process

A very common, typical occurrence on general-purpose computing systems that
occurs thousands and thousands of time in a ‘unit’ time..

When getting an interrupt, the system saves the current context of the process
being executed (that is, saves its ‘state’).

Its PCB is used to store the interrupted process’s state and all necessary
parameters for resumption.

The PCB will be later used resumption.

Changing the CPU from one process to another is called context switching.

Context-switch time is overhead; the system does no useful work while switching

 The time it takes for context switching is very hardware dependent.(10 mics…)


Copying register contents to/from memory takes time – not much, but when
this is done many thousands of time in a minute, this overhead adds up.
The details of preserving the address space and related issues are discussed in
memory management, because the ‘space’ used by the currently executing
process may well need to be freed up for some other process(es) – but maybe not.
Operating System Concepts
3.20
Silberschatz, Galvin and Gagne ©2005
Shells and the Kernel
 Before we get into Operations on Processes, I
want to present a short discussion on Shells and
the Kernel.
 These may be sometimes confusing…

The Kernel and the Shell
Operating System Concepts
3.21
Silberschatz, Galvin and Gagne ©2005
Kernel
 WE know that the kernel is that part of an operating system software where
the real work is done. It performs all those tasks dealing with input and
output devices such as managing disk drives, CPU scheduling, memory
management, and so very much more..
 The Unix kernel is the part of the operating system that contains code for

Sharing the CPU and RAM between competing processes
 Processing all system calls
 Handling peripherals
 The kernel is a program that is loaded from disk into RAM when the computer
is first turned on (recall System Boot).
 It always stays in RAM and runs until the system is turned off or crashes (or
at least ‘most’ of it).
 Kernel design and coding must be terribly efficient.
 is written mostly in C, although some parts are written in assembly
language for efficiency reasons.
 User programs make use of the kernel via the system call interface, which
we have talked about.
Operating System Concepts
3.22
Silberschatz, Galvin and Gagne ©2005
Kernel Subsystems
 Kernel facilities are typically divided into five subsystems
with specific hunks of functionality for managing each:

Memory management

Process management

Inter-process communications (IPC)

Input/output

File management
 These are the facilities / management / control / services that
the kernel provides for us as services for both user and
system process.
 The ‘kernel’ is the ‘big cookie.’
Operating System Concepts
3.23
Silberschatz, Galvin and Gagne ©2005
Kernel Subsystems – a view of files and I/O…
 Hierarchically, a view that addresses file management, I/O, and
peripherals may appear as:
File management
Input/output
peripherals
And…
Operating System Concepts
3.24
Silberschatz, Galvin and Gagne ©2005
Kernel Subsystems
 And views at lower level are:
Inter-process Communication
Process Management
Memory Management
CPU & RAM
hardware
Operating System Concepts
3.25
Silberschatz, Galvin and Gagne ©2005
Talking to the Kernel
 Processes access kernel facilities via the system call interface
(SCI), and peripherals (special ‘files’) communicate with the
kernel via hardware interrupts.
  System calls and hardware interrupts are the
only ways in which the outside world can talk to
the kernel.
 Since these are very important, we will devote a lot of time to
these in the appropriate sections.
 But for now, you may get a visual on this by:
Operating System Concepts
3.26
Silberschatz, Galvin and Gagne ©2005
Visual on Talking to the Kernel
Process
This visual says a great
deal!
Process
Process
System Calls
Kernel
Hardware Interrupts
peripheral
Operating System Concepts
peripheral
3.27
peripheral
Silberschatz, Galvin and Gagne ©2005
Shells
 A shell is a program that sits between you and the raw Unix operating
system.
 There are four shells commonly supported by Unix vendors, and we’ve
mentioned them in the past. They are the:
 1. Bourne shell (sh)
 2. Korn shell (ksh)





3. C shell (csh), and the
 4. Bourne Again shell (bash).
There is a common core set of operations that make life in the Unix system
a little easier and somewhat consistent.
Example: all the shells allow the output of a process to be stored in a file or
‘piped’ to another process. (e.g. $ ls |more )
They also allow the use of wildcards in filenames so its easy to say things
like “list all of the files whose names end with the suffix ‘.c’ as in
$ ls
*.c
Pick your shell. These all work in the same way.
Operating System Concepts
3.28
Silberschatz, Galvin and Gagne ©2005
Shells
 Shell selection is a matter of taste, power, compatibility, and
availability.
 Interactive Work: Some feel that the C shell is better than the
Bourne shell for interactive work, but slightly worse in some
respects for script programming.
 Upwards Compatibility: The Korn shell was designed to be
upwards compatible with the Bourne shell, and it incorporates the
best features of the Bourne and C shell, plus some more features
of its own.
 Optimal: Bash also takes a ‘best of all worlds’ approach including
features from all the other major shells.
Operating System Concepts
3.29
Silberschatz, Galvin and Gagne ©2005
Bourne Shell
 The Bourne shell comes with absolutely every
version of UNIX. The others come with most versions
these days, but you might not always find your favorite.
 Bash probably ships with the fewest versions of UNIX,
but is available for the most.
 (Steve Bourne is a personal friend of mine. We work
each year together at the ICPC (Inter Collegiate
Programming Contest sponsored by IBM). He works with
Upsilon Pi Epsilon (UPE) to assist us in annual
registration of programming teams.)
Operating System Concepts
3.30
Silberschatz, Galvin and Gagne ©2005
Shells – last for now
 It is very simple to change your default login shell, if you wish. You
only need to know the full pathnames of the four shells normally,
/bin/ksh or /bin/sh, etc.
 Each shell’s start up is a wee bit different.
 Most execute some special start-up file usually in the user’s home
directory that contains
 some initialization information (some info is usually gotten from
your ‘profile’),
 displays a prompt, and
 waits for a user command.
 Entering a control-D on a line of its own is interpreted by the shell as
‘end of input’ and causes shell to terminate; otherwise, the shell
executes the user’s command.
 Bottom line for those interested in the ‘shell game’ is that the shell is
essentially an interface to the kernel, where all the work is done.
Operating System Concepts
3.31
Silberschatz, Galvin and Gagne ©2005
End of Chapter 3.1