Chapter 3 - Processes

1
 Introduction

 communication takes place between processes

 a process is a program in execution
 from OS perspective, management and scheduling of pro-
cesses is important
 other important issues arise in distributed systems
 multithreading to enhance performance
 how are clients and servers organized
 process or code migration to achieve scalability and to
dynamically configure clients and servers
 software agents: a collection of processes trying to reach
a common goal

2
 3.1 Threads and their Implementation
 threads can be used in both distributed and nondistributed
systems
 Threads in Nondistributed Systems
 a process has an address space (containing program text
and data) and a single thread of control, as well as other
resources such as open files, child processes, accounting
information, etc.

three processes each with one thread one process with three threads 3
 each thread has its own program counter, registers, stack,
and state; but all threads of a process share address space,
global variables and other resources such as open files, etc.

4
 Threads take turns in running
 Threads allow multiple executions to take place in the same
process environment, called multithreading
 Thread Usage – Why do we need threads?
 e.g., a wordprocessor has different parts; parts for
 interacting with the user
 formatting the page as soon as changes are made
 timed savings (for auto recovery)
 spelling and grammar checking, etc.
1. Simplifying the programming model: since many activi-
ties are going on at once
2. They are easier to create and destroy than processes
since they do not have any resources attached to them
3. Performance improves by overlapping activities if there is
too much I/O; i.e., to avoid blocking when waiting for in-
put or doing calculations, say in a spreadsheet
4. Real parallelism is possible in a multiprocessor system
5
 having finer granularity in terms of multiple threads per
process rather than processes provides better performance
and makes it easier to build distributed applications
 in nondistributed systems, threads can be used with shared
data instead of processes to avoid context switching over-
head in interprocess communication (IPC)

context switching as the result of IPC

6
 Threads in Distributed Systems
 Multithreaded Clients
 consider a Web browser; fetching different parts of a page

can be implemented as a separate thread, each opening its

own TCP/IP connection to the server or to separate and
replicated servers
 each can display the results as it gets its part of the page

 Multithreaded Servers
 servers can be constructed in three ways

1. single-threaded process

 it gets a request, examines it, carries it out to completion

before getting the next request

 the server is idle while waiting for disk read, i.e., system

calls are blocking

7
2. threads
 threads are more important for implementing servers
 e.g., a file server
 the dispatcher thread reads incoming requests for a file
operation from clients and passes it to an idle worker
thread
 the worker thread performs a blocking disk read; in which
case another thread may continue, say the dispatcher or
another worker thread

a multithreaded server organized in a dispatcher/worker model 8

 3. finite-state machine
 if threads are not available
 it gets a request, examines it, tries to fulfill the request
from cache, else sends a request to the file system; but
instead of blocking it records the state of the current re-
quest and proceeds to the next request
 Summary

Model Characteristics
Single-threaded process No parallelism, blocking system calls

Threads Parallelism, blocking system calls (thread

only)
Finite-state machine Parallelism, nonblocking system calls
three ways to construct a server

9
 3.2 Anatomy of Clients
 Two issues: user interfaces and client-side software for dis-
tribution transparency

1. User Interfaces
 to create a convenient environment for the interaction of a

human user and a remote server; e.g. mobile phones with

simple displays and a set of keys
 GUIs are most commonly used

 The X Window System (or simply X)

 it has the X-kernel: the part of the OS that controls the

terminal (monitor, keyboard, pointing device like a
mouse)
 contains all terminal-specific device drivers through the
library called xlib

10
the basic organization of the X Window System

11
2. Client-Side Software for Distribution Transparency
 in addition to the user interface, parts of the processing

and data level in a client-server application are executed at

the client side
 moreover, client software can also include components to

achieve distribution transparency

 e.g., replication transparency: assume a distributed sys-

tem with remote objects; the client proxy can send re-
quests to each replica, collects all responses and passes a
single return value to the client application

12
a possible approach to transparent replication of a remote object using a
client-side solution

13
 3.3 Servers: General Design Issues
 issues
 how to organize servers?
 where do clients contact a server?
 whether and how a server can be interrupted
 whether or not the server is stateless

1. how to organize servers?

 iterative server
 the server itself handles the request and returns the re-

sult
 concurrent server
 it passes a request to a separate process or thread and

waits for the next incoming request; e.g., a multi-

threaded server

14
2. where do clients contact a server?
 using endpoints or ports at the machine where the server
is running where each server listens to a specific end-
point
 how do clients know the endpoint of a service?
 globally assign endpoints for well-known services; e.g.

FTP is on TCP port 21, HTTP is on TCP port 80

 for services that do not require preassigned endpoints,

it can be dynamically assigned by the local OS

 how can the client know this endpoint? two approaches

a. have a daemon running and listening to a well-known

endpoint like in DCE; it keeps track of all endpoints of
services on the collocated server
 the client will first contact the daemon which pro-

vides it with the endpoint, and then the client con-

tacts the specific server

15
 Client-to-server binding using a daemon as in DCE
b. use a superserver (as in UNIX) that listens to all endpoints
and then forks a process to take care of the request; this is
instead of having a lot of servers running simultaneously and
most of them idle

Client-to-Server binding using a superserver as in UNIX 16

3. whether and how a server can be interrupted
 for instance, a user may want to interrupt a file transfer,
may be it was the wrong file
 let the client exit the client application; this will break the
connection to the server; the server will tear down the
connection assuming that the client had crashed
or
 let the client send out-of-bound data, data to be pro-
cessed by the server before any other data from the
client; the server may listen on a separate control end-
point; or send it on the same connection as urgent data
as is in TCP
4. whether or not the server is stateless
 a stateless server does not keep information on the state
of its clients; for instance a Web server
 a stateful server maintains information about its clients;
for instance a file server that allows a client to keep a lo-
cal copy of a file and can make update operations
B 17
 3.4 Code Migration
 so far, communication was concerned on passing data
 we may pass programs, even while running and in heteroge-
neous systems
 code migration also involves moving data as well: when a
program migrates while running, its status, pending signals,
and other environment variables such as the stack and the
program counter also have to be moved

18
1. Reasons for Migrating Code
 to improve performance; move processes from heavily-
loaded to lightly-loaded machines (load balancing)
 to reduce communication: move a client application that per-
forms many database operations to a server if the database
resides on the server; then send only results to the client
 to exploit parallelism (for nonparallel programs): e.g., copies
of a mobile program moving from site to site searching the
Web

M1
19
2. Models for Code Migration
 a process consists of three segments: code segment (set of
instructions), resource segment (references to external re-
sources such as files, printers, ...), and execution segment
(to store the current execution state of a process such as
private data, the stack, the program counter)
 Weak Mobility
 transfer only the code segment and may be some initial-
ization data; in this case a program always starts from its
initial stage, e.g. Java Applets
 execution can be by the target process (in its own ad-
dress space like in Java Applets) or by a separate
process

20
 Strong Mobility
 transfer code and execution segments; helps to migrate a
process in execution
 can also be supported by remote cloning; having an ex-
act copy of the original process and running on a differ-
ent machine; executed in parallel to the original process;
UNIX does this by forking a child process
 migration can be
 sender-initiated: the machine where the code resides or
is currently running; e.g., uploading programs to a
server; may need authentication or that the client is a reg-
istered one
 receiver-initiated: by the target machine; e.g., Java Ap-
plets; easier to implement

21
Summary of models of code migration

alternatives for code migration

22
3. Migration and Local Resources
 how to migrate the resource segment
 not always possible to move a resource; e.g., a reference to
TCP port held by a process to communicate with other pro-
cesses
 Types of Process-to-Resource Bindings
 Binding by identifier (the strongest): a resource is referred
by its identifier; e.g., a URL to refer to a Web page or an FTP
server referred by its Internet address
 Binding by value (weaker): when only the value of a resource
is needed; in this case another resource can provide the
same value; e.g., standard libraries of programming lan-
guages such as C or Java which are normally locally avail-
able, but their location in the file system may vary from site
to site
 Binding by type (weakest): a process needs a resource of a
specific type; reference to local devices, such as monitors,
printers, ...
23
 in migrating code, the above bindings cannot change, but the
references to resources can
 how can a reference be changed? depends whether the re-
source can be moved along with the code, i.e., resource-to-
machine binding
 Types of Resource-to-Machine Bindings
 Unattached Resources: can be easily moved with the migrat-
ing program (such as data files associated with the program)
 Fastened Resources: such as local databases and complete
Web sites; moving or copying may be possible, but very
costly
 Fixed Resources: intimately bound to a specific machine or
environment such as local devices and cannot be moved
 we have nine combinations to consider

24
 Resource-to machine binding
Unattached Fastened Fixed
By identifier MV (or GR) GR (or MV) GR
Process-to-re-
source binding By value CP (or MV, GR) GR (or CP) GR
By type RB (or GR, CP) RB (or GR, CP) RB (or GR)

actions to be taken with respect to the references to local re-

sources when migrating code to another machine
 GR: Establish a global system wide reference
 MV: Move the resource
 CP: Copy the value of the resource
 RB: Rebind process to a locally available resource

 Exercise: for each of the nine combinations, give example re-

sources

25
 Migration in Heterogeneous Systems
 distributed systems are constructed on a heterogeneous col-
lection of platforms, each with its own OS and machine ar-
chitecture
 heterogeneity problems are similar to those of portability
 easier in some languages; for scripting languages the
source code is interpreted; for Java an intermediary code is
generated by the compiler for a virtual machine
 in weak mobility
 since there is no runtime information, compile the source
code for each potential platform

26
 in strong mobility
 difficult to transfer the execution segment since there
may be platform-dependent information such as register
values;
 one possible solution: restrict migration to specific
points in the execution of a program, i.e., only when a
subroutine is called
 the runtime system maintains a machine-independent

program stack, called migration stack; for this the

compiler must generate code to update the migration
stack whenever a subroutine is entered or exited

27
 3.5 Software Agents and Agent Technology
 a software agent is an autonomous unit (process) capable of
performing a task in collaboration (i.e., it communicates)
with other, possibly remote, agents
 it is capable of reacting to, and initiating changes (proactive)
in its environment, possibly with users and other agents
 a collaborative agent is an agent that forms part of a multia-
gent system, in which agents seek to achieve some common
goal through collaboration; e.g., in arranging meetings
 a mobile agent is an agent having the capability to move be-
tween different machines; e.g., to retrieve information dis-
tributed across a large heterogeneous network such as the
Internet
 an interface agent is an agent that assists an end user in the
use of one or more applications and has learning capabili-
ties (it is adaptive); e.g., those that bring buyers and sellers
together

28
 an information agent is an agent that manages information
from different sources such as ordering and filtering; e.g. an
email agent filtering unwanted mail from its owner’s mailbox,
or automatically distributing incoming mail into appropriate
subject-specific mailboxes

29
 Agent Technology
 we need support to develop agent systems; for instance a
middleware consisting of generally-used components of
agents in distributed systems
 FIPA - Foundation for Intelligent Physical Agents - develops
a general model for software agents
 agent platform: where agents are registered at, and operate;
provides basic services such as creating and deleting
agents, locating agents, interagent communication, ...; it
may include the following
 agent management: keep track of the agents for the as-
sociated platform; provides facilities for creating and
deleting agents, looking for the current endpoint for a
specific agent by providing a naming service to globally
and uniquely identify an endpoint
 local directory service: where agents can look up what
other agents on the platform have to offer
 agent communication channel (ACC): for agents to com-
municate by exchanging messages in multiagent systems
30
 Agent Communication Languages (ACL)
 ACL: an application-level protocol where communication be-
tween agents takes place
 a message has a purpose and content
 purpose
 to request a specific service
 to respond to a request
 to inform about an event
 to propose during negotiation

31
 ACL messages consist of a header and the actual content
 the header has different fields:
 a field to identify the purpose of the message,
 fields to identify the sender and the receiver,
 a field to identify the language or encoding scheme for
the content (since an ACL does not prescribe the format
or language in which the message content is expressed),
 a field to identify a standardized mapping of symbols to
their meaning called ontology (if no common understand-
ing of interpreting data)

32