Course Name : Parallel and Distributed Computing

Course Code: (482 CCS-4)

Chapter 3
Processes
TOPICS
3.1 Threads

3.2 Virtualization ‫االفتراضية‬

3.3 Clients

3.4 Servers

3.5 Code migration

2
 Process
 A process consists of an execution environment
together with one or more threads.
 A thread is the operating system abstraction of an
activity.
 An execution environment is the unit of resource
management: a collection of local kernel
managed resources to which its threads have
access.
 An execution environment consists of :
 An address space
 Thread synchronization and communication
resources (e.g., semaphores, sockets)
 Higher-level resources (e.g., file systems,
windows)

3
 3.1 Threads

 Threads are schedulable activities attached to

processes.
 The aim of having multiple threads of execution is :
 To maximize degree of concurrent execution
between operations
 To enable the overlap of computation with input
and output
 To enable concurrent processing on
multiprocessors.
 Threads can be helpful within servers:
 Concurrent processing of client’s requests can
reduce the tendency for servers to become
bottleneck.
• E.g. one thread can process a client’s
request while a second thread serving
another request waits for a disk access to
complete.
4
 3.2 Virtualization:
System virtualization:
 The goal of system virtualization is to provide multiple
virtual machines over the underlying physical machine
architecture, with each virtual machine running a separate
operating system instance.
 System virtualization is implemented by a thin layer of
software on top of the underlying physical machine
architecture; this layer is referred to as a virtual machine
monitor or hypervisor.
 This virtual machine monitor provides an interface based
closely on the underlying physical architecture.
 More precisely, in full virtualization the virtual machine
monitor offers an identical interface to the underlying
physical architecture

5
Types of Virtualization
 There are many different ways in which virtualization can be realized.
An overview of these various approaches is described by Smith and
Nair [2005a].
 To understand the differences in virtualization, it is important to
realize that computer systems generally offer four different types of
interfaces, at three different levels:
1. An interface between the hardware and software, referred to as the
instruction set architecture (ISA), forming the set of machine
instructions. This set is divided into two subsets:
 Privileged instructions, which are allowed to be executed only by the
operating system.
 General instructions, which can be executed by any program.
2. An interface consisting of system calls as offered by an operating
system.
3. An interface consisting of library calls, generally forming what is
known as an application programming interface (API). In many
cases, the afore mentioned system calls are hidden by an AP
6
3.3 Clients
 Networked user interfaces
 A major task of client machines is to provide the means for
users to interact with remote servers. There are roughly two
ways in which this interaction can be supported.
 First, for each remote service the client machine will have a
separate counterpart that can contact the service over the
network. A typical example is a calendar running on a
user’s smartphone that needs to synchronize with a
remote, possibly shared calendar. In this case, an
application-level protocol will handle the synchronization,
as shown in Figure 3.10(a).
 A second solution is to provide direct access to remote
services by offering only a convenient user interface.
Effectively, this means that the client machine is used only
as a terminal with no need for local storage, leading to an
application-neutral solution as shown in Figure 3.10(b).

7
8
3.4 Servers

 General design issues

 A server is a process implementing a specific
service on behalf of a collection of clients. In
essence, each server is organized in the same way:
it waits for an incoming request from a client and
subsequently ensures that the request is taken care
of, after which it waits for the next incoming
request.

9
Contacting a server: end points
 Another issue is where clients contact a server.
 In all cases, clients send requests to an end point, also
called a port, at the machine where the server is running.
Each server listens to a specific end point. How do clients
know the end point of a service? One approach is to globally
assign end points for well-known services.
 For example, servers that handle Internet FTP requests always
listen to TCP port 21. Likewise, an HTTP server for the World
Wide Web will always listen to TCP port 80.
 These end points have been assigned by the Internet
Assigned Numbers Authority (IANA), and are documented
in [Reynolds and Postel, 1994]. With assigned end points,
the client needs to find only the network address of the
machine where the server is running. Name services can be
used for that purpose.
10
 Interrupting a server
 Another issue that needs to be taken into account
when designing a server is whether and how a server
can be interrupted.
 For example, consider a user who has just decided to
upload a huge file to an FTP server. Then, suddenly
realizing that it is the wrong file, he wants to interrupt
the server to cancel further data transmission. There are
several ways to do this.
 One approach that works only too well in the current
Internet (and is sometimes the only alternative) is for
the user to abruptly exit the client application (which
will automatically break the connection to the server),
immediately restart it, and pretend nothing happened.
The server will eventually tear down the old connection,
thinking the client has probably crashed
11
 Example: The Apache Web server
 An interesting example of a server that balances the separation
between policies and mechanisms is the Apache Web server. It is
also an extremely popular server, estimated to be used to host
approximately 50% of all Web sites. Apache is a complex piece of
software, and with the numerous enhancements to the types of
documents that are now offered in the Web, it is important that
the server is highly configurable and extensible, and at the same
time largely independent of specific platforms.
 Making the server platform independent is realized by
essentially providing its own basic runtime environment, which
is then subsequently implemented for different operating
systems. This runtime environment, known as the Apache
Portable Runtime (APR), is a library that provides a platform
independent interface for file handling, networking, locking,
threads, and so on. When extending Apache, portability is
largely guaranteed provided that only calls to the APR are made
and that calls to platform-specific libraries are avoided

12
3.5 Code migration

 So far, we have been mainly concerned with

distributed systems in which communication is
limited to passing data. However, there are
situations in which passing programs, sometimes
even while they are being executed, simplifies the
design of a distributed system. In this section, we
take a detailed look at what code migration
actually is.

13
14
15
16
17
As the first problem , there are, three ways to handle migration (which can be
combined):

18
19
End of the Chapter