Chapter-3

Process Concept
An operating system executes a variety of programs that run as a process.

Process – a program in execution; process execution must progress in

sequential fashion. No parallel execution of instructions of a single process

Multiple parts

The program code, also called text section

• The program code, also called text section

Current activity including program counter, processor registers

Stack containing temporary data

Function parameters, return addresses, local variables

Data section containing global variables

Heap containing memory dynamically allocated during run time

• Program is passive entity stored on disk (executable file); process is active

• Program becomes process when an executable file is loaded into memory
• Execution of program started via GUI mouse clicks, command line entry of its
name, etc.
• One program can be several processes
• Consider multiple users executing the same program

Process in Memory

Chapter-3 1
 Process State
• As a process executes, it changes 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 processor

Terminated: The process has finished execution

Diagram of Process State

Chapter-3 2
 Threads
So far, process has a single thread of execution

Consider having multiple program counters per process

• Multiple locations can execute at once

Multiple threads of control -> threads

Must then have storage for thread details, multiple program counters in PCB

Explore in detail in Chapter 4

Process Scheduling
Process scheduler selects among available processes for next execution on
CPU core

Goal -- Maximize CPU use, quickly switch processes onto CPU core

Maintains scheduling queues of processes

Ready queue – set of all processes residing in main memory, ready and
waiting to execute

Chapter-3 3
 Wait queues – set of processes waiting for an event (i.e., I/O)

Processes migrate among the various queues

Context Switch

Chapter-3 4
 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 via a context switch

Context of a process represented in the PCB

Context-switch time is pure overhead; the system does no useful work while
switching

• The more complex the OS and the PCB è the longer the context switch

• Time dependent on hardware support

• Some hardware provides multiple sets of registers per CPU è multiple contexts
loaded at once

Operations on Processes
• System must provide mechanisms for:

Process creation

Process termination

Process Creation
Parent process create children processes, which, in turn create other
processes, forming a tree of processes

Generally, process identified and managed via a process identifier (pid)

Resource sharing options

Parent and children share all resources

Children share subset of parent’s resources

Parent and child share no resources

• Execution options

Parent and children execute concurrently

Parent waits until children terminate

Chapter-3 5
Chapter-3 6
 • Some operating systems do not allow child to exists if its parent has terminated. If a
process terminates, then all its children must also be terminated.

cascading termination. All children, grandchildren, etc., are terminated.

The termination is initiated by the operating system.

The parent process may wait for termination of a child process by using the
wait()system call. The call returns status information and the pid of the
terminated process

pid = wait(&status);

If no parent waiting (did not invoke wait()) process is a zombie

If parent terminated without invoking wait(), process is an orphan

Android Process Importance Hierarchy

• Mobile operating systems often have to terminate processes to reclaim system
resources such as memory. From most to least important:

Foreground process

Visible process

Service process

Background process

Empty process

• Android will begin terminating processes that are least important.

Chapter-3 7
 Interprocess Communication
Processes within a system may be independent or cooperating

Cooperating process can affect or be affected by other processes, including

sharing data

Reasons for cooperating processes:

Information sharing

Computation speedup

Modularity

Convenience

Cooperating processes need interprocess communication (IPC)

Two models of IPC

Shared memory

Message passing

Chapter-3 8
 Producer-Consumer Problem
• Paradigm for cooperating processes:

• producer process produces information that is consumed by a consumer

process
• Two variations:

• unbounded-buffer places no practical limit on the size of the buffer:

Producer never waits

Consumer waits if there is no buffer to consume

bounded-buffer assumes that there is a fixed buffer size

Producer must wait if all buffers are full

Consumer waits if there is no buffer to consume

IPC – Message Passing

Processes communicate with each other without resorting to shared variables

IPC facility provides two operations:

send(message)

Chapter-3 9
 receive(message)

The message size is either fixed or variable

• If processes P and Q wish to communicate, they need to:

Establish a communication link between them

Exchange messages via send/receive

• Implementation issues:

How are links established?

Can a link be associated with more than two processes?

How many links can there be between every pair of communicating

processes?

What is the capacity of a link?

Is the size of a message that the link can accommodate fixed or variable?

Is a link unidirectional or bi-directional?

Implementation of Communication Link

• Physical:

Shared memory

Hardware bus

Network

• Logical:

Direct or indirect

Synchronous or asynchronous

Automatic or explicit buffering

Direct Communication
• Processes must name each other explicitly:

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

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

Chapter-3 10
 • Properties of communication link

Links are established automatically

A link is associated with exactly one pair of communicating processes

Between each pair there exists exactly one link

The link may be unidirectional, but is usually bi-directional

Indirect Communication
• Messages are directed and received from mailboxes (also referred to as ports)

Each mailbox has a unique id

Processes can communicate only if they share a mailbox

• Properties of communication link

Link established only if processes share a common mailbox

A link may be associated with many processes

Each pair of processes may share several communication links

Link may be unidirectional or bi-directional

• Operations

Create a new mailbox (port)

Send and receive messages through mailbox

Delete a mailbox

• Primitives are defined as:

send(A, message) – send a message to mailbox A

receive(A, message) – receive a message from mailbox A

• Mailbox sharing

P1, P2, and P3 share mailbox A

P1, sends; P2 and P3 receive

Who gets the message?

• Solutions

Allow a link to be associated with at most two processes

Chapter-3 11
 Allow only one process at a time to execute a receive operation

Allow the system to select arbitrarily the receiver. Sender is notified who the
receiver was.

Synchronization
Message passing may be either blocking or non-blocking
• Blocking is considered synchronous

Blocking send - the sender is blocked until the message is received

Blocking receive - the receiver is blocked until a message is available

• Non-blocking is considered asynchronous

Non-blocking send -- the sender sends the message and continue

Non-blocking receive -- the receiver receives:

A valid message, or

Null message

• Different combinations possible

• If both send and receive are blocking, we have a rendezvous

Buffering
Queue of messages attached to the link.

Implemented in one of three ways

1. Zero capacity – no messages are queued on a link. Sender must wait for
receiver (rendezvous)

2. Bounded capacity – finite length of n messages Sender must wait if link full

3. Unbounded capacity – infinite length Sender never waits

Examples of IPC Systems - POSIX

• POSIX Shared Memory

Process first creates shared memory segment shm_fd = shm_open(name,

O CREAT | O RDWR, 0666);

Chapter-3 12
 Also used to open an existing segment

Set the size of the object

ftruncate(shm_fd, 4096);

Use mmap() to memory-map a file pointer to the shared memory object

Reading and writing to shared memory is done by using the pointer returned by
mmap().

Examples of IPC Systems - Mach

• Mach communication is message based

Even system calls are messages

Each task gets two ports at creation - Kernel and Notify

Messages are sent and received using the mach_msg() function

Ports needed for communication, created via

mach_port_allocate()

Send and receive are flexible; for example four options if mailbox full:

Wait indefinitely
Wait at most n milliseconds
Return immediately
Temporarily cache a message

Examples of IPC Systems – Windows

• Message-passing centric via advanced local procedure call (LPC) facility

Only works between processes on the same system

Uses ports (like mailboxes) to establish and maintain communication

channels

Communication works as follows:

4The client opens a handle to the subsystem’s connection port object.

The client sends a connection request.

Chapter-3 13
 4The server creates two private communication ports and returns the
handle to one of them to the client.

The client and server use the corresponding port handle to send
messages or callbacks and to listen for replies.

Pipes
Acts as a conduit allowing two processes to communicate

Issues:

Is communication unidirectional or bidirectional?

In the case of two-way communication, is it half or full-duplex?

Must there exist a relationship (i.e., parent-child) between the

communicating processes?

Can the pipes be used over a network?

• Ordinary pipes – cannot be accessed from outside the process that created it.
Typically, a parent process creates a pipe and uses it to communicate with a child
process that it created.
• Named pipes – can be accessed without a parent-child relationship.

Chapter-3 14
 Ordinary Pipes
Ordinary Pipes allow communication in standard producer-consumer style

Producer writes to one end (the write-end of the pipe)

Consumer reads from the other end (the read-end of the pipe)

Ordinary pipes are therefore unidirectional

Require parent-child relationship between communicating processes

• Windows calls these anonymous pipes

Named Pipes
Named Pipes are more powerful than ordinary pipes

Communication is bidirectional

No parent-child relationship is necessary between the communicating processes

Several processes can use the named pipe for communication

Provided on both UNIX and Windows systems

Communications in Client-Server Systems

Sockets

Remote Procedure Calls

Sockets
A socket is defined as an endpoint for communication

Chapter-3 15
 Concatenation of IP address and port – a number included at start of message
packet to differentiate network services on a host

The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8

Communication consists between a pair of sockets

All ports below 1024 are well known, used for standard services

Special IP address 127.0.0.1 (loopback) to refer to system on which process is

running

Chapter-3 16