Introduction to Distributed

System

Chapter Two: Processes

 Outline

• Threads and their Implementation

• Anatomy of Clients
• Servers and Design Issues
• Code Migration
 Introduction

• Communication takes place between processes

• A process is defined a program in execution.
• From OS perspective, management and scheduling of
processes is important.
• Other important issues arise in distributed systems
include:
– Multi threading to enhance performance by overlapping
communication and local processing
– How are clients and servers organized and server design issues
– Process or code migration to achieve scalability and to
dynamically configure clients and servers
 Threads and their Implementation

• how are processes and threads related?

• Process tables or PCBs(Process control block) are used
to keep track of processes
• there are usually many processes executing concurrently
• processes should not interfere with each other; sharing
resources by processes is transparent
• this concurrency transparency has a high price;
allocating resources for a new process and context
switching take time
• a thread also executes independently from other
threads; but no need of a high degree of concurrency
transparency thereby resulting in better performance
 Threads in Non distributed 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. Process 1 Process 2 Process 3

processes each with one thread one process with three threads
 Threads in Non distributed Systems

• 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.
 Threads in Non distributed Systems
• Threads take turns in running
• Threads allow multiple executions to take place in the
same process environment, called multi threading
1.Simplifying the programming model: since many activities
are going on at once more or less independently
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
input or doing calculations, say in a spreadsheet
4. Real parallelism is possible in a multiprocessor system
 Threads in Non distributed Systems

• In non distributed systems, threads can be used

with shared data instead of processes to avoid
context switching overhead interprocess
communication (IPC).

context switching as the result of IPC

 Thread Implementation
• Threads are usually provided in the form of a thread
package.
• The package contains operations to create and destroy a
thread, operations on synchronization variables such as
mutexes and condition variables
• Two approaches of constructing a thread package
a. construct a thread library that is executed entirely in
user mode (the OS is not aware of threads)
– cheap to create and destroy threads; just allocate and free
memory
– context switching can be done using few instructions; store and
reload only CPU register values
– disadvantage: invocation of a blocking system call will block the
entire process to which the thread belongs and all other threads
in that process
 Thread Implementation
b. implement them in the OS’skernel
– let the kernel be aware of threads and schedule them
– expensive for thread operations such as creation and
deletion since each requires a system call
• solution: use a hybrid form of user-level and kernel-level
threads, called lightweight process (LWP)
 Threads in Distributed Systems

• An important property of threads is that they can provide

a convenient means of allowing blocking system calls
without blocking the entire process in which the thread is
running.
• This property makes threads particularly attractive to use
in distributed systems as it makes it much easier to
express communication in the form of maintaining
multiple logical connections at the same time.
• We illustrate this point by taking a closer look at
multithreaded clients and servers, respectively.
 Multithreaded Clients

• consider a Web browser; fetching different parts

of a page can be implemented as a separate
thread, each opening its own TCP connection to
the server
• each can display the results as it gets its part of
the page
• parallelism can also be achieved for replicated
servers since each thread request can be
forwarded to separate replicas
 Multithreaded Servers
• servers can be constructed in three ways
A. Single-threaded process
– it gets a request, examines it, carries it out to completion before
getting the next request
B. 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
C. 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
A multithreaded server organized in a dispatcher/worker model.

Three ways to construct a server.

read about virtualization (the illusion of having more resources than we actually have): pages 79 -82
 Anatomy of Clients
Two issues: user interfaces and client-side software for
distribution transparency
A. 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) as an example
• it has the X kernel: the part of the OS that controls the
terminal (monitor, keyboard, pointing device like a
mouse) and is hardware dependent
The basic organization of the X Window System.
 Anatomy of Clients
b. 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
• an example is embedded client software for ATMs, cash
registers, etc.
• moreover, client software can also include components
to achieve distribution transparency
• e.g., replication transparency
• assume a distributed system with replicated servers; the
client proxy can send requests to each replica and a
Client-side software can transparently collect all
responses and pass a single response to the client
application.
 Anatomy of Clients

Transparent replication of a server using a client-side solution.

 Servers and Design Issues

a. How to organize servers?

Iterative server
• the server itself handles the request and returns
the result
Concurrent server
• it passes a request to a separate process or
thread and waits for the next incoming request;
e.g., a multithreaded server;
 Servers and Design Issues

b. 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
endpoint

• 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
 Code Migration

• so far, communication was concerned on

passing data
• we may pass programs, even while running and
in heterogeneous 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
 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 performs 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 (called a mobile agent is
called in search engines) moving from site to site
searching the Web.
 Models for Code Migration
• code migration doesn’t only mean moving code; in some
cases, it also means moving the execution status of a
program, pending signals, and other parts of the
execution environment
• a process consists of three segments: code segment
(set of instructions), resource segment (references to
external resources 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)
• alternatives for code migration
– weak versus strong mobility
– is it sender-or receiver-initiated
– is it executed at the target process or in a separate process (for
weak mobility); migrate or clone process (for strong mobility)
 Models for Code Migration

Weak Mobility
• transfer only the code segment and may be some
initialization 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 address space like in Java Applets)
but the target process and local resources must be protected
(security) or
– by a separate process; still local resources must be protected
(security)
 Models for Code Migration

Strong Mobility (or process migration )

• transfer code and execution segments; helps to migrate a process in
execution; stop execution, move it, and then resume execution from
where it is stopped
• 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 registered one;
crawlers to index Web pages
– receiver-initiated: by the target machine; e.g., Java Applets;
easier to implement
• In a client-server model, receiver-initiated is easier to implement
since security issues are minimized; if clients are allowed to send
code (sender-initiated), the server must know them since they may
access resources such as disk on the server
Summary of models of code migration
Types of Process-to-Resource Bindings

• Binding by identifier (the strongest): a resource is

referred by its identifier; the process requires that
resource; e.g., a URL to refer to a Web page or an FTP
server referred by its Internet (IP) 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 languages such as C or Java which are
normally locally available, 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, printer
 Resource-to-Machine Bindings

• Unattached Resources: can be easily moved

with the migrating 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
Thank you!