Chapter 3 - Processes

1
 Introduction

 In this chapter, we take a closer look at

 the role of processes and threads in distributed systems

 explain why they are so important
 how they can be used to build applications
 What is actually meant by code migration
 Types of code migration

2
 Introduction(con’t…)

 In the pervious chapter, we concentrated on communication in

distributed system.
 Communication takes place between processes
 The concept of a process originates from the field of operating
systems where it is generally defined as a program in execution.
 From OS perspective, management and scheduling of processes is
important.
 However, when it comes to distributed systems, other issues
turn out :
 Multithreading can help us in enhancing
performance
 How are clients and servers organized
 Process or code migration can help in achieving
scalability and can also help to dynamically configure
clients and servers.

3
 Introduction(con’t…)

 To understand the role of threads in distributed systems, it is important to

understand how OS execute the program.
 To execute a program, an operating system creates:
 a number of virtual processors,
 each virtual processor running different program.
 To keep the track of these virtual processors, the operating system has a
process table, containing:
 CPU register values,
 memory maps,
 open files,
 privileges,
 etc.

4
 Introduction(con’t…)

 So, what is a process?

 A process is often defined as a program in execution

 Or, a program that is currently being executed on one of the

virtual processors is called process.

 Please note that multiple processes may be concurrently

sharing the same CPU.

5
 3.1 Threads(con’t…)

 What is tread?
 A thread is the smallest unit of execution within a process.
 Or a thread is a segment of a process
 Threads allow for parallelism within a process
 It is good for applications that require concurrent tasks
 a process can have multiple threads

6
 3.1 Threads
 Types of tread:
 Single treaded process
 Multi treaded process
 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, etc.

Process 1 Process 2 Process 3

three processes each with one thread one process with three threads 7
 3.1 Threads(con’t…
 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.

8
 3.1 Threads

 Threads can be used in both Non distributed systems and

Distributed systems; can be seen into two ways:

1. Tread usage in Non distributed systems and

2. Tread usage in Distributed systems

9
 3.1 Threads (con’t…)

1. Thread Usage in Nondistributed Systems:

 Before discussing the role of threads in distributed systems, let us first consider their usage in nondistributed
systems.
 In nondistributed systems, there are multithreaded and single treaded process.
 In a single treaded process, there is blocking system.

Why do we need multithreaded process?

 To allow multiple executions to take place in the same process environment, for example a wordprocessor
has different parts; parts for
 interacting with the user
 formatting the page as soon as changes are made
 time savings (for auto recovery)
 spelling and grammar checking, etc.

10
 3.1 Threads (con’t…)

 Advantages of multithreaded process:

1. Simplifying the programming model:
 since many activities 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 input or doing
calculations, say in a spreadsheet
4. Real parallelism is possible in a multiprocessor system
5. Efficient Utilization of System Resources

11
 3.1 Threads (con’t…)

2. Thread Usage in Distributed Systems:

 An important property of threads is that they can provide

 non-blocking system.

 multiple logical connections at the same time.

 This property makes threads particularly attractive to use in

distributed systems
 We illustrate this point by taking a closer look at multithreaded

clients and servers, respectively.

 In distribute systems, there are two types of multithreaded :

1. Multithreaded Clients

2. Multithreaded Servers

12
 3.1.1.Threads in Distributed Systems (con’t…)

1. Multithreaded Clients
 A typical example where this happens is in Web browsers, in
which.
 Fetching different parts of a page can be implemented as a
separate thread,
 Each thread sets up a separate connection to the server
 Or each opening pages has its own TCP/IP connection to
the server or to replicated server
 each can display the results as it gets its part of the page
 Summary: multithreaded Web browsers several
in
connections can be opened simultaneously.

13
 3.1.1.Threads in Distributed Systems (con’t…)

2. Multithreaded Servers
 Multithreading in distributed systems can be found at the
server side.
 In distributed system, servers can be constructed in three
ways
1. Single-threaded server
2. Multithreaded server
3. Finite-state machine

14
 3.1.1.Threads in Distributed Systems (con’t…)

1. Single-threaded server: Steps

 It gets a request,
 It 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

 Consequently, requests from other clients cannot be handled.

15
 3.1.1.Threads in Distributed Systems (con’t…)

2. Multithreaded server:
 Multithreads are more important for implementing servers
 e.g., a file server  Steps
 The dispatcher thread reads incoming requests
 Examining the request
 The server chooses an idle worker thread and hands it the
request

A multithreaded server organized in a dispatcher/worker model

16
 3.1.1.Threads in Distributed Systems (con’t…)

3. Finite-state machine
 Please note that in the first two possible designs, there is
blocking system calls
 A third possibility is to run the server as a big finite-
state machine.
 Instead of blocking, it records the state of the current request
in a table and then gets/proceeds to the next request.
 Or
 if threads are not available in server
 it gets a request,
 examines it,
 tries to fulfill the request from cache, else sends a request
to the file system;

17
 3.1.1.Threads in Distributed Systems (con’t…)

 Summary of possible server designs:

Model Characteristics
Single-threaded server No parallelism, blocking system calls
Parallelism, blocking system calls
Multithreads server
(thread only)
Parallelism, nonblocking system
Finite-state machine
calls

three ways to construct/ design a server

 Please note that nonblocking calls is hard to program.

18
 3.2. Client: General Design Issues

 Reading Assignment

19
 3.3 Servers: General Design Issues
 Issues
1. How to organize servers?
2. Where do clients contact a server?
3. Whether and how a server can be interrupted
4. Whether or not the server is stateless

20
 3.3 Servers: General Design Issues (con’t…)
1. How to organize servers?
 Two primary types of server architectures are Iterative Servers and Concurrent
Servers.
 Iterative server
 the server itself handles the request and returns the result
 How It Works
 Server waits for a client request.
 Accepts a single request from a client.
 Processes the request.
 Sends the response back to the client.
 Moves to the next request
 Disadvantage: Blocking, poor scalability, and Not Suitable for High
Loads
 Concurrent server
 it passes a request to a separate process or thread and waits for the next incoming
request;
 Responds to clients simultaneously
 e.g., a multithreaded server

21
 3.3 Servers: General Design Issues (con’t…)

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 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
 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 provides it with
the endpoint, and then the client contacts the specific server

22
3.3 Servers: General Design Issues (con’t…)

Client-to-server binding using a daemon as in DCE

23
 3.3 Servers: General Design Issues (con’t…)

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
 Hardware/Network Failures
 Programming errors or crashes in server
 Servers may be intentionally interrupted for updates,
upgrades, or repairs.

24
 3.3 Servers: General Design Issues (con’t…)

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
local copy of a file and can make update operations

25
 3.4 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

26
 3.4.1 Reasons for Migrating Code
 Traditionally, code migration in distributed systems took place in the
form of process migration in which an entire process was moved
from one machine to another.
 Problem: Performance
 Solution: using code migration
 move only code between machines

 Reasons for migrating code are:

 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 moving from site to site searching the Web.

27
 3.4.2. Models for Migrating Code
 To get a better understanding of the different models for
code migration, we have to understand segments in a
process.
 A process consists of three segments:
 Code segment
 Contains the set of instructions
 Resource segment
 Contains references to external resources such as files,
printers, devices, and so on.
 Execution segment
 Is used to store the current execution state of a process
 consisting of private data, the stack, and the program
counter

28
 3.4.2. Models for Migrating Code(con’t…)
 There two models for migrating conde between machines:
1. Weak Mobility
2. Strong Mobility

29
 3.4.2. Models for Migrating Code(con’t…)

1. 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) or by a separate
process

30
 3.4.2. Models for Migrating Code(con’t…)

2. Strong Mobility:
 transfer code and execution segments; helps to migrate a
process in execution
 can also be supported by remote cloning; having an exact copy
of the original process and running on a different machine;
executed in parallel to the original process; UNIX does this by
forking a child process

31
3.4.2. Models for Migrating Code(con’t…)
 More on models for migration
 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
 receiver-initiated: by the target machine; e.g., Java
Applets; easier to implement

32
 3.4.2. Models for Migrating Code(con’t…)
Summary of models of code migration

alternatives for code migration

33
 3.4.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 processes
 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 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, printers, ...

34
 3.4.3. Migration and Local Resources(cont…)

 in migrating code, the above bindings cannot change, but the

references to resources can
 how can a reference be changed? depends whether the
resource 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
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
 we have nine combinations to consider 35
 3.4.3. Migration and Local Resources(cont…)
Resource-to machine binding

Unattached Fastened Fixed

By identifier MV (or GR) GR (or MV) GR
Process-to-
resource 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 resources 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 resources

36
Thank You!

37