Topic 4: Processes

 We discussed inter-process communication earlier

 We will delve into the process itself, which play an important
role in a DS
 The concept of process originates from OS point of view.
 A program refers to the code that is stored in a file. ( Geet)
 A process is an executing or ready to execute program in a
computer (Sangeet)
 The concepts involved are:
 Process Context-switching
 Thread Multi-threading
 Context Process / Code Migration
Software Agents
Process

 Process = Program + execution context

 Execution context = process context + memory map
Stack
 Process context: state of the processor -- value of PC, all registers etc.
 Memory map: Regions of memory that have been allocated to the process
 Text: the machine instructions (compiled prog)
 Data: initialized static and global data
 Bss: uninitialized static data (ex. Global uninitialized strings, numbers, struct
etc)
 Heap: dynamically allocated memory (by say malloc or new) Heap
 Stack: the call stack which holds not just return addresses but also local
variables, temp data and saved registers. Data+bss
 A process shares physical memory, disks, printers and other resources with Text
other processes
Process states

 A process is running if it currently has the CPU

and is executing the code
Running
 A process is ready if it could run if and only if it
had the CPU
Pre-emption
 A process is blocked when it cannot run because I/O
it is waiting for some event to occur. (eg. For an
I/O operation to complete)
scheduler
 Scheduler is responsible for prioritizing which
process deserve to run next from the ready list
 OS maintains the blocked list Ready Blocked
 If a running process doesn’t get blocked
I/O
(computation intensive) eventually a h/w timer complete
will interrupt the OS and cause OS to stop (pre-
empt) the process and put it in ready list.
Process states…more detail User
Running
System call or
interrupt return
 Created
 Temporary state when a process is created. Kernel
 When initial memory is allocated, stack is set up, PCB is fully Running
initialized, it moves to ready state and placed in ready list.
 User-mode running Pre-emption
 Running in user-mode is the normal execution of a program. I/O
scheduler
 Performing a system call involves a mode-switch, causing the
process flow of control to switch to the kernel causing the
processor to run in kernel mode.
 Kernel code is executing but is still aware that the process is
currently active and the flow of control is on the process.
Ready Blocked
 Kernel-mode running I/O
 Kernel decides to schedule another process to execute and the complete
current process is pre-empted. The process goes to ready state.
 Once the process is rescheduled to run again, the kernel mode
restores the user’s state to the process and return to the
process to user-mode running.
Created
Process context

 Process context
 The context of a process is its state. It comprises of text (program code), all global variables
and data structures ( data + bss), all dynamic memory (heap), context of user and kernel
stacks and all machine registers.
 Context-switching
 When a process is running, the system is said to be in the context of that process.
 When the kernel decided to execute another process, it does a context-switch.
 The kernel has to save enough information so that it can switch back to the earlier process
and continue executing exactly where it left off.
 When a process executes a system call and has to change from the user-mode to kernel
mode, context-switching occurs.
 Enabling concurrently sharing of the same CPU and other H/W resources by multiple
processes, context-switching provides concurrency transparency in a DS.
Context-Switching in IPC

User space
 IPC requires kernel intervention
 Process A will first switch from user-mode to kernel-mode Process A Process B
(S1)
 S1: switch from user space to kernel space
 Within the kernel, a process context-switch takes place
(S2)
 S2: switch from process-context (A) to process-context (B) S1 S3
 Process B can be activated by switching from kernel mode S2
to user mode
kernel space
 S3: switch from kernel space to user space
 Switching involves change of memory maps
 Flushing of Transaction Look-aside Buffer (TLB)
 TLB : cache of frequently-used memory address
translation)
Process Table and Process Control Blocks

 To keep track of processes, OS maintains a process table.

 Each entry in the process table corresponds to a particular process and contain fields containing info that
kernel needs to know about the process, It is called PCB.
 PCB fields are
 Machine state (registers, PC, SP….)
 Parent process and list of child processes
 Process state (ready I running I blocked)
 Event description if the process is blocked
 Memory map
 Open file descriptors
 Owner, access privilages, signal privilages
 Scheduling parameters
 Time
 Process group etc.
Thread of execution

 A process is a program in memory along with dynamically allocated storage (heap), the
stack and the execution context comprising the state of processor – registers, PC etc.
 Process has two compoments
 1. Program + heap
 2. stack + SP + PC + registers etc
 2nd component is important for execution flow of the program
 PC keeps track of which instruction to execute next
 Instructions affect the registers
 Subroutine call/return instructions and instructions that push or pop registers on the
stack on entry and exit for function call adjust contents of the stack and SP
 This stream of instruction is the thread of execution of the process.
 A traditional process has one thread of execution
Multi-threading

 In a traditional OS, each process has an address space and a single thread of control or thread of
execution or simply a thread.
 A process may be multi-threaded
 Same program contains multiple concurrent threads of execution
 As OS that supports multi-threading has a scheduler responsible for pre-empting and scheduling all
threads of all processes.
 In a multi-threaded process all of its threads share the same memory or address space and open files.
 Within the shared memory each thread get its own stack, sp, instruction pointer, registers etc.
 Since memory is shared there is no memory protection among the threads in a process.
 Switching back and forth among multiple multi-threaded processes, a system gives the illusion of parallel
processing.
 In a DS main contribution of multi-threading is that it allows clients and servers overlap in communication
and local processing, resulting in a high performance.
 Pure software engineering reason to use multi-threading is to structure a collection of cooperating threads.
PCB and TCB
 An OS keeps track of process specific information
in PCBs in process table.
 Thread specific information are stored in a data
structure called Thread Control Block (TCB).
 Each PCB will be linked to a list of TCBs PCB PCB PCB
 Information required by OS to store for each
thread TCB TCB TCB
 Thread ID, Stored registers, SP, IP, Stack, Signal
mark
 Priority (scheduling info) TCB TCB TCB
 State: (running I blocked I terminated I ready )
 Information shared among threads within a
process
 Text segment, Data segment, Bss, Open file
descriptor, Signals
 Current working directory
Methods of thread implementation:
User space threads
 Threads are generally provided in the form of packages. User space

 A thread package contains operations to create and destroy

threads, operations on mutexes and condition variables.
 A thread package may be implemented in user space, kernel
space or hybrid thr.
 User space threads
Thread table
 The package is entirely in user space. Kernel knows noting
about them
 Kernel manages only traditional single threaded processes.
 Threads run on the top of Run-Time System (RTS) Process table

 A collection of procedures in RTS manages the threads. Kernel space

 Each process needs its own private thread table managed by
the run-time system
 Thread table has PC, SP, registers, state etc.
Methods of thread implementation:
User space threads….
 Advantages
 User-level thread package can be implemented on
an OS that doesn’t support threads
 Thread switching is faster than trapping to kernel.
 Local thread scheduler is faster than kernel call
 (no trap, no context-switching, no cash flushing ….)
 Each process has its own customerized scheduling
algorithms
 Limitations
 Blocking system call implementation is a major
problem. Let a thread reads from keyboard, it will
stop all threads.
 Page fault: If a thread causes a papge fault, the
kernel naturally blocks the entire process.
Methods of thread implementation:
Kernel space threads
User space

 Kernel maintains the thread table along with

traditional process table
 Kernel schedules the thread. No individual
scheduler is required.
 Advantages
 Blocking unblocking are done by the kernel
 Limitations
 Thread operations are costly. Every thread Process table Thread table
operation (creation, deletion, synchronization
etc) are done by the kernel, requiring a system Kernel space
call.
 Switching thread-contexts is as expensive as
switching process context. As a result, most of
the benefits of using threads instead of
processes then disappears.
Methods of thread implementation:
Hybrid threads (Light Weight Processes)
 Generally referred as Light-Weight Processes (LWP)
 Use kernel level thread User space
 Multiplex user level threads onto some or all kernel level
threads
 Kernel is aware of only kernel level threads and schedules
those. LWP

 Some of those threads have multiple user level treads

multiplexed on the top of them
 Thus each kernel level thread has many user-level threads Kernel space
 These user-level threads are created destroyed and
scheduled just like user-level threads in user space.
 Case studies of multi-threaded clients and servers in a DS
are discussed in the book (Chapter 3). Study them for
further comprehension.
Code Migration

 The main theme of communication is the exchange of data.

 The main theme of code migration is exchange of program / code along with data.
 Migration of a running process from one machine to another is costly and intricate.
 Objectives of code migration
 Improvement of performance in a DS
 Load balancing. Load is a function of CPU queue length.
 Minimization of communication
 Flexibility : dynamic configuration of distributed systems.
Scenario

 Consider a client server system. Server manages a huge database. If the client
needs to do many database operations involving large quantity of data, it may be
better to migrate part of the client application to server and send only the result.
 Principle is: : process data closer to where those data reside.
 Similarly, if a client needs to fill up forms, then validation part of the server can be
migrated to the client.
 Exploit parallelism: A search query in the form of a mobile program moves from
site to site collect information or several copies of such a program is
simultaneously send to different sites. (Web crawler).
Dynamically configured DS

 Traditional DS partitions applications into different parts and each part is allocated
to different executor apriori. It is a statically configured DS. (multi-layered C/S)
 Let the server provide the client implementation. The client dynamically
downloads the implementation, goes through the initialization steps, invokes the
server.
 This approach enables dynamic configuration of a DS. (Java applet/servlet)
Models for code migration

 Fugetta framework: In this framework a process consists of three segments:

 Code segment
 Set of instructions
 Resource segment
 External resources needed by the process
 Files, printers, devices, other processes
 Execution segment
 Current state of execution of the process.
 Private data, stack, PC etc.
Weak and strong mobility

 Weak mobility
 Transfer only code segment and perhaps some initialization data
 Transferred program is always started from the initial state.
 Only requirement is that the target machine can execute the code (portability). Ex java
applet
 Benefit: simlicity
 Strong mobility
 Transfer code segment and execution segment.
 Running process can be stopped, migrated to the target machine, and resumed the
execution.
Sender or receiver initiated migration

 Sender-initiated
 Migration is initiated by the source machine, where the code currently resides or being
executed.
 Uploading programs to a computer server
 Search program across Internet to perform query at servers
 Requires that the client is already registered and authenticated at the server. Because the
migrated code may access server’s resources.
 Receiver-initiated
 Migration is initiated by the target machine
 Downloading a code (Java applets)
 Instead of migrating a running process physically, remote cloning the process can be
done.
Migration and local resources

 Migration of code and execution segments are discussed

 The resource segment requires some special attention.
 Resource segment cannot always be simply transferred along with the other
segments without being changed.
 For example TCP port is held in resource segment. When a process moves to
another location, it will have to give up the port and request a new one at the
destination.
 Transferring a reference to a file by means of an URL is not problematic.
 A URL remains valid irrespective of machine where the process that holds the URL
resides.
Fugetta Framework suggestions

 Fugetta Framework suggests three types of process to resource binding

 Three types of binding
 1. Binding by identifier (Strongest)
 Process refers to resource by identifier
 Use of URL as identifier
 2. Binding by value (Weaker)
 When only the value of a resource is needed.
 Execution of the process would not be affected if another resource provide the same value.
 Ex, C- program refers to standard libraries, which are supposed to be locally available in the target machine.
 3. Binding by type (Weakest)
 Process indicates the need of only a resource of special type , such as monitors, printers etc.
Fugetta Framework suggestions...

 When migrating code, we often need to change references to resources, but cannot
affect process-to-resource binding. We need to consider resource-to-machine bindings.
 Fugetta framework suggests three types of Resource-to-machine bindings
 1. Unattached resources: can be easily moved between machines, typically data
files associated only with the code that is to be migrated.
 2. Fastened resources: Moving & Copying is possible but only at relatively high cost.
 Ex: local databases, complete websites etc.
 Such resources are not dependent on current machines but infeasible to move them to
another environment.
 Fixed resources : intimately bound to a specific machine or environment and cannot
be moved.
 local devices, local comm. endpoints(sockets)
Combinations
Migration in heterogenous System

 We assumed that migrated code can easily be executed at the target machine.
 This assumption is true in case of homogeneous system
 Migration is such system require that code segment can be executes on each
platform.
 recompilation of the original source may be required.
Software Agents in DS

 So far we studied processes from different perspectives:

 Thread of control
 Communication (client server)
 Mobility
 Software Agent
 A S/W agent is an autonomous process capable of reacting to, initiating
changes in, its environment, possibly in collaboration with users & other agents.
 A s/w agent is a process with additional capability to act on its own and take
initiatives where appropriate.
Distinguishing features

 capability of act on its own

 take initiations where appropriate
 co-operation with other agents.
Types of S/W agents

 Collaboration Agents
 autonomy + co-operation=> collaboration
 Agents seek to achieve some common goal through collaboration.
 eg. Meeting scheduler.
 Each attendee is represented by a s/w agent.
 Given all the individual constraints wrt time travel, place, personal agenda etc. separate
agents would collaborate and set up a meeting.
 Inter-agent communication
Mobile agent

 A mobile agent is simply an agent having the capability to move between different
machines.
 Agents are autonomous and actively interact with the environment. There needs
strong mobility.
 However, agents with weak mobility are also useful. ( Eg. D’agent)
 Foundation for Intelligent Physical Agents (FIPA)
Interface agent

 S/w agents that assists an end-user in the use of one or more applications are
interface agents.
 It has an learning ability.
 More interaction better assistance.
Information agents

 Closely related to information agents

 Main function is to manage information from different sources.
 Management includes ordering, filtering, collating etc.
 For example, email agent filters unwanted mails from it’s owners mail box
 Automatically distribute incoming mails into appropriate subject-specific mail-
boxes.
Agent Technology

 Agent Communication Channel (ACC)

 Communication through message exchange
 Internet Inter-ORB protocol (IIOP) in CORBA
 Agent Communication Language (ACL)
 Application level communication protocol
 Interaction based on ACL differentiates a s/w agent from a normal process
 A message consists of purpose and content
FIPA ACL
Message purpose Description Message content

INFORM Inform that a given proposition is true proposition

QUERY-IF Query whether a given proposition is proposition

true

QUERY-REF Query for a given object expression

CFP Ask for a proposition Proposal specifics

PROPOSE Provide a proposal proposal

ACCEPT-PROPOSAL Tell that a given proposal is accepted Proposal ID

REJECT-PROPOSAL Tell that a given proposal is rejected Proposal ID

REQUEST Request that an action be performed Action specification

SUBSCRIBE Subscribe to an information source Reference to a source