Distributed System

Unit-I

A distributed computer system consists of multiple software components that are on

multiple computers that do not share memory or a clock. They communicate by exchanging
messages over a network, but run as a single system.

The computers that are in a distributed system can be physically close together and
connected by a local network, or they can be geographically distant and connected by a
wide area network.

A distributed system can consist of any number of possible configurations, such as

mainframes, personal computers, workstations, minicomputers, and so on.

Three significant characteristic of distributed systems are: concurrency of components, lack

of a global clock, and independent failure of components.

Examples of Distributed systems

 Department computing cluster
 Corporate systems
 Cloud systems (e.g. Google, Microsoft, etc.)

characteristics of distributed systems:

1. Concurrency of components: In a network of computers, concurrent program
execution is the norm for sharing resources. The capacity of the system to handle
shared resources can be increased by adding more resources to the network.

2. No global clock: When programs need to cooperate they coordinate their actions by
exchanging messages. Close coordination often depends on a shared idea of the time
at which the programs’ actions occur. But it turns out that there are limits to the
accuracy with which the computers in a network can synchronize their clocks – there
is no single global notion of the correct time. This is a direct consequence of the fact
that the only communication is by sending messages through a network.

3. Independent failures of components: All computer systems can fail and the system
designer is responsible for planning for the consequences of possible failures Each
component of a distributed system can fail independently, leaving the others still
running The failure may be due to a crash or a slow response

Key characteristics of distributed systems

1. Resource sharing
2. Openess
 3. Concurrency
4. Scalability
5. Fault Tolerance
6. Transparency

Goals of distributed system

The four important goals that should be met for an efficient distributed system are as
follows:
1. Connecting Users and Resources:
 The main goal of a distributed system is to make it easy for users to access remote
resources and to share them with others in a controlled way.
 It is cheaper to le a printer be shared by several users than buying and maintaining
printers for each user.
 Collaborating and exchanging information can be made easier by connecting users
and resource.
2. Transparency:
 It is important for a distributed system to hide the location of its process and
resource. A distributed system that can portray itself as a single system is said to be
transparent.
 The various transparencies need to be considered are access, location, migration,
relocation, replication, concurrency, failure and persistence.
 Aiming for distributed transparency should be considered along with performance
issues.
3. Openness:
 Openness is an important goal of distributed system. The openness of a computer
system is the characteristics that determines whether the system can be extended
and re-implemented in various ways.
 Open distributed system must be flexible making it easy to configure and add new
components without affecting existing components.
4. Scalability:
 Scalability is one of the most important goals which are measured along three different
dimensions.
 First, a system can be scalable with respect to its size which can add more user and
resources to a system.
 Second, users and resources can be geographically apart.
 Third, it is possible to manage even if many administrative organizations are spanned.

Architecture for Distributed Systems

Software concept of Distributed system

Distributed operating system:

1. The distributed operating system handles a group of independent computers and
makes them look like an ordinary centralised operating system.
2. The main goal is to hide and manage hardware resources.
3. It is a tightly-coupled operating system for multi processor and homogeneous multi-
computers.
4. Distributed OS follows n tier client/server architecture
5. It communicates with all the computer using message passing interface(MPI).
6. Two types of DOS- multi computer operating system and multiprocessor operating
system.
Eg: Microsoft-Distributed Component Object Model(DCOM)

Fig. General structure of a multicomputer operating system

Network operating system:

1. A network operating system is specifically designed for heterogeneous multicomputer
system such as workstation, personal computer, where multiple hardware and network
platforms are supported.
2. The main goal is to offer local services to remote clients.
3. It is a loosely coupled operating system for heterogeneous multi-computers.
4. Network OS follows 2 tier Client server architecture
5. The network operating system sends files in order to communicate with other nodes.
6. Two types of NOS-,Peer-to-peer and client/server architecture.
Eg: Novell NetWare
Middleware
 The middleware sits between the platform and the application. The term middleware
applies to a software layer that provides a programming abstraction as well as masking
the heterogeneity of the underlying networks, hardware, operating systems and
programming languages.
 In addition to solving the problems of heterogeneity, middleware provides a uniform
computational model for use by the programmers of servers and distributed
applications. Possible models include remote object invocation, remote event
notification, remote SQL access and distributed transaction processing. For example,
 CORBA provides remote object invocation, which allows an object in a program running
on one computer to invoke a method of an object in a program running on another
computer.

Examples of middleware include the following:

 Java RMI
 CORBA
 DCOM

Hardware Concepts
 Although all Distributed Systems consist of multiple CPUs, there are different ways of
interconnecting them and how they communicate
 Flynn (1972) identified two essential characteristics to classify multiple CPU computer systems:
the number of instruction streams and the number of data streams
Uniprocessors SISD
Array processors are SIMD - processors cooperate on a single problem
MISD - No known computer fits this model
Distributed Systems are MIMD - a group of independent computers each with its own program
counter, program and data
 MIMD can be split into two classifications
Multiprocessors - CPUs share a common memory
Multicomputers - CPUs have separate memories
 Can be further subclassified as
Bus - All machines connected by single medium (e.g., LAN, bus, backplane, cable)
Switched - Single wire from machine to machine, with possibly different wiring patterns (e.g,
Internet)
I. Tightly coupled systems. In these systems, there is a single systemwide primary memory
(address space) that is shared by all the processors [Fig. l.1(a)]. If any processor writes, for
example, the value 100 to the memory location x, any other processor subsequently reading
from location x will get the value 100. Therefore, in these systems, any communication
between the processors usually takes place through the shared memory.
2. Loosely coupled systems. In these systems, the processors do not share memory, and
each processor has its own local memory [Fig. l.1(b)]. If a processor writes the value 100 to
the memory location x, this write operation will only change the contents of its local
memory and will not affect the contents of the memory of any other processor.
Hence, if another processor reads the memory location x, it will get whatever value was
there before in that location of its own local memory. In these systems, all physical
communication between the processors is done by passing messages across the network
that interconnects the processors.
Distributed Computing Models With diagrams
The various models that are used for building distributed computing systems can be
classified into 5 categories:
1.Minicomputer Model

 The minicomputer model is a simple extension of the centralized time-sharing system.

 A distributed computing system based on this model consists of a few minicomputers
interconnected by a communication network were each minicomputer usually has
multiple users simultaneously logged on to it.
 Several interactive terminals are connected to each minicomputer.Each user logged on
to one specific minicomputer has remote access to other minicomputers.
 The network allows a user to access remote resources that are available on some
machine other than the one on to which the user is currently logged.The minicomputer
model may be used when resource sharing with remote users is desired.
 The early ARPA net is an example of a distributed computing system based on the
minicomputer model.
2.Workstation Model
 A distributed computing system based on the workstation model consists of several
workstations interconnected by a communication network.
 An organization may have several workstations located throughout an infrastructure
were each workstation is equipped with its own disk & serves as a single-user computer.
 In such an environment, at any one time a significant proportion of the workstations are
idle which results in the waste of large amounts of CPU time.
 Therefore, the idea of the workstation model is to interconnect all these workstations by
a high-speed LAN so that idle workstations may be used to process jobs of users who are
logged onto other workstations & do not have sufficient processing power at their own
workstations to get their jobs processed efficiently.
 Example: Sprite system & Xerox PARC.

3.Workstation–Server Model

 The workstation model is a network of personal workstations having its own disk & a
local file system.
 A workstation with its own local disk is usually called a diskful workstation & a
workstation without a local disk is called a diskless workstation. Disk less workstations
have become more popular in network environments than diskful workstations, making
the workstation-server model more popular than the workstation model for building
distributed computing systems.
 A distributed computing system based on the workstation-server model consists of a
few minicomputers & several workstations interconnected by a communication
network.
 In this model, a user logs onto a workstation called his or her home workstation. Normal
computation activities required by the user's processes are performed at the user's
home workstation, but requests for services provided by special servers are sent to a
 server providing that type of service that performs the user's requested activity &
returns the result of request processing to the user's workstation.
 Therefore, in this model, the user's processes need not migrated to the server machines
for getting the work done by those machines.
 Example: The V-System.
4.Processor–Pool Model:

 The processor-pool model is based on the observation that most of the time a user
does not need any computing power but once in a while the user may need a very
large amount of computing power for a short time.
 Therefore, unlike the workstation-server model in which a processor is allocated to
each user, in processor-pool model the processors are pooled together to be shared
by the users as needed.
 The pool of processors consists of a large number of microcomputers &
minicomputers attached to the network.
 Each processor in the pool has its own memory to load & run a system program or
an application program of the distributed computing system.
 In this model no home machine is present & the user does not log onto any machine.
 This model has better utilization of processing power & greater flexibility.
 Example: Amoeba & the Cambridge Distributed Computing System.
5.Hybrid Model:
 The workstation-server model has a large number of computer users only
performing simple interactive tasks &-executing small programs.
 In a working environment that has groups of users who often perform jobs needing
massive computation, the processor-pool model is more attractive & suitable.
 To combine Advantages of workstation-server & processor-pool models, a hybrid
model can be used to build a distributed system.
 The processors in the pool can be allocated dynamically for computations that are
too large or require several computers for execution.
  The hybrid model gives guaranteed response to interactive jobs allowing them to be
more processed in local workstations of the users

Issues in designing distributed systems/ Challenges of Distributed system

1. Heterogeneity
The Internet enables users to access services and run applications over a heterogeneous
collection of computers and networks. Internet consists of many different sorts of network
their differences are masked by the fact that all of the computers attached to them use the
Internet protocols to communicate with one another. For eg., a computer attached to an
Ethernet has an implementation of the Internet protocols over the Ethernet, whereas a
computer on a different sort of network will need an implementation of the Internet
protocols for that network.
2. Openness
The openness of a computer system is the characteristic that determines whether the
system can be extended and re-implemented in various ways.The openness of distributed
systems is determined primarily by the degree to which new resource-sharing services can
be added and be made available for use by a variety of client programs.
3. Security
Many of the information resources that are made available and maintained in distributed
systems have a high intrinsic value to their users. Their security is therefore of considerable
importance. Security for information resources has three components: confidentiality,
integrity, and availability.
a. Confidentiality : protection against disclosure to unauthorized individuals.
b. Integrity : protection against alteration/corruption
c. Availability : protection against interference with the means to access the resources
4. Scalability
Distributed systems operate effectively and efficiently at many different scales, ranging
from a small intranet to the Internet. A system is described as scalable if it will remain
effective when there is a significant increase in the number of resources and the number of
users.

5. Failure handling
Computer systems sometimes fail. When faults occur in hardware or software, programs
may produce incorrect results or may stop before they have completed the intended
computation. Failures in a distributed system are partial – that is, some components fail
while others continue to function. Therefore the handling of failures is particularly difficult.
6. Concurrency
Where applications/services process concurrency, it will effect a conflict in operations with
one another and produce inconsistence results.
Each resource must be designed to be safe in a concurrent environment.
7. Transparency
One of the main goals of a distributed operating system is to make the existence of multiple
computers invisible (transparent) and provide a single system image to its users. That is, a
distributed operating system must be designed in such a way that a collection of distinct
machines connected by a communication subsystem appears to its users as a virtual
uniprocessor. Achieving complete transparency is a difficult task and requires that several
different aspects of transparency be supported by the distributed operating system.

The eight forms of transparency identified by the International Standards Organization's

Reference Model for Open Distributed Processing [ISO 1992] are-

a) Access Transparency- Access transparency means that users should not need or be able
to recognize whether a resource (hardware or software) is remote or local. This implies that
the distributed operating system should allow users to access remote resources in the same
way as local resources.
b) Location transparency: The users cannot tell where resources are located
The two main aspects of location transparency are as follows:
1. Name transparency- This refers to the fact that the name of a resource (hardware or
software) should not reveal any hint as to the physical location of the resource. That is,
the name of a resource should be independent of the physical connectivity or topology
of the system or the current location of the resource.
2. User mobility- This refers to the fact that no matter which machine a user is logged
onto, he or she should be able to access a resource with the same name. That is, the
user should not be required to use different names to access the same resource from
two different nodes of the system.
b) Migration transparency: Resources can move at will without changing their names
c) Replication transparency: For better performance and reliability, almost all distributed
operating systems have the provision to create replicas (additional copies) of files and other
resources on different nodes of the distributed system. In these systems, both the existence
of multiple copies of a replicated resource and the replication activity should be transparent
to the users.
d) Failure Transparency-Failure transparency deals with masking from the users' partial
failures in the system, such as a communication link failure, a machine failure, or a storage
device crash. A distributed operating system having failure transparency property will
continue to function, perhaps in a degraded form, in the face of partial failures. For
example, suppose the file service of a distributed operating system is to be made failure
transparent.
e) Concurrency transparency: It enables several processes to operate concurrently using
shared resources without interference between them.
f) Parallelism transparency: Activities can happen in parallel without users knowing.
g) Scaling Transparency- The aim of scaling transparency is to allow the system to expand in
scale without disrupting the activities of the users.
h) Performance transparency: It allows the system to be reconfigured to improve
performance as loads vary.
8. Quality of service
Once users are provided with the functionality that they require of a service, such as the file
service in a distributed system, we can go on to ask about the quality of the service
provided. The main non-functional properties of systems that affect the quality of the
service experienced by clients and users are reliability, security and performance.
Adaptability to meet changing system configurations and resource availability has been
recognized as a further important aspect of service quality.
9. Reliability
One of the original goals of building distributed systems was to make them more reliable
than single-processor systems. The idea is that if a machine goes down, some other machine
takes over the job. A highly reliable system must be highly available, but that is not enough.
Data entrusted to the system must not be lost or garbled in any way, and if files are stored
redundantly on multiple servers, all the copies must be kept consistent. In general, the more
copies that are kept, the better the availability, but the greater the chance that they will be
inconsistent, especially if updates are frequent.
10. Performance
If a distributed system is to be used, its performance must be at least as good as a
centralized system. That is, when a particular application is run on a distributed system, its
overall performance should be better than or at least equal to that of running the same
application on a single-processor system. However, to achieve this goal, it is important that
the various components of the operating system of a distributed system be designed
properly; otherwise, the overall performance of the distributed system may turn out to be
worse than a centralized system. Unfortunately, achieving this is easier said than done.

Advantages of distributed system

1. Inherently Distributed Applications: Distributed computing systems come into existence
in some very natural ways. For example, several applications are inherently distributed
in nature and require a distributed computing system for their realization. For instance,
in an employee database of a nationwide organization, the data pertaining to a
particular employee are generated at the employee's branch office, and in addition to
the global need to view the entire database, there is a local need for frequent and
immediate access to locally generated data at each branch office. Applications such as
these require that some processing power be available at the many distributed locations
for collecting, pre processing, and accessing data, resulting in the need for distributed
computing systems. Some other examples of inherently distributed applications are a
computerized worldwide airline reservation system, a computerized banking system in
which a customer can deposit/withdraw money from his or her account from any branch
 of the bank, and a factory automation system controlling robots and machines all along
an assembly line.
2. Better price-performance ratio: With the rapidly increasing power and reduction in the
price of microprocessors, combined with the increasing speed of communication networks,
distributed computing systems potentially have a much better price-performance ratio than
a single large centralized system. For example, we saw how a small number of CPUs in a
distributed computing system based on the processor-pool model can be effectively used by
a large number of users from inexpensive terminals, giving a fairly high price-performance
ratio as compared to either a centralized time-sharing system or a personal computer.
3. Information Sharing among Distributed Users: Another reason for the emergence of
distributed computing systems was a desire for efficient person-to-person
communication facility by sharing information over great distances. In a distributed
computing system, information generated by one of the users can be easily and
efficiently shared by the users working at other nodes of the system.
4. Resource Sharing: Information is not the only thing that can be shared in a distributed
computing system. Sharing of software resources such as software libraries and
databases as well as hardware resources such as printers, hard disks, and plotters can
also be done in a very effective way among all the computers and the users of a single
distributed computing system.
5. Shorter Response times and Higher Throughput: Due to multiplicity of processors,
distributed computing systems are expected to have better performance than single-
processor centralized systems. The two most commonly used performance metrics are
response time and throughput of user processes. That is, the multiple processors of a
distributed computing system can be utilized properly for providing shorter response
times and higher throughput than a single-processor centralized system. For example, if
there are two different programs to be run, two processors are evidently more powerful
than one because the programs can be simultaneously run on different processors.
Furthermore, if a particular computation can be partitioned into a number of sub
computations that can run concurrently, in a distributed computing system all the sub
computations can be simultaneously run with each one on a different processor.
Distributed computing systems with very fast communication networks are increasingly
being used as parallel computers to solve single complex problems rapidly. Another
method often used in distributed computing systems for achieving better overall
performance is to distribute the load more evenly among the multiple processors by
moving jobs from currently overloaded processors to lightly loaded ones.
6. Higher Reliability
Reliability refers to the degree of tolerance against errors and component failures in a
System. A reliable system prevents loss of information even in the event of component
failures. The multiplicity of storage devices and processors in a distributed computing
system allows the maintenance of multiple copies of critical information within the system
and the execution of important computations redundantly to protect them against
catastrophic failures. With this approach, if one of the processors fails, the computation can
be successfully completed at the other processor, and if one of the storage devices fails, the
information can still be used from the other storage device. Furthermore, the geographical
distribution of the processors and other resources in a distributed computing system limits
the scope of failures caused by natural disasters.
7. Extensibility and Incremental Growth
Another major advantage of distributed computing systems is that they are capable of
incremental growth. That is, it is possible to gradually extend the power and functionality of
a distributed computing system by simply adding additional resources (both hardware and
software) to the system as and when the need arises. For example, additional processors
can be easily added to the system to handle the increased workload of an organization that
might have resulted from its expansion. Incremental growth is a very attractive feature
because for most existing and proposed applications it is practically impossible to predict
future demands of the system. Extensibility is also easier in a distributed computing system
because addition of new resources to an existing system can be performed without
significant disruption of the normal functioning of the system. Properly designed distributed
computing systems that have the property of extensibility and incremental growth are
called open distributed systems.
8. Better Flexibility in Meeting User’s Needs
Different types of computers are usually more suitable for performing different types of
computations. For example, computers with ordinary power are suitable for ordinary data
processing jobs, whereas high-performance computers are more suitable for complex
mathematical computations .In a centralized system , the users have to perform all types of
computations on the only available computer. However, a distributed computing system
may have a pool of different types of computers, in which case the most appropriate one
can be selected for processing a user's job depending on the nature of the job. For instance,
we saw that in a distributed computing system that is based on the hybrid model,
interactive jobs can be processed at a user's own workstation and the processors in the pool
may be used to process non interactive, computation-intensive jobs.

Disadvantages of Distributed systems

1. Multiple Points of Failures: the failure of one or more participating computers, or one
or more network links, can generate trouble.
2. Security Concerns: In a distributed system, there are more opportunities for
unauthorized attack.
3. Software: Distributed software is harder to develop than conventional software; hence,
it is more expensive.
4. Complexity: Distributed computing systems are much more complex and difficult to
build than the traditional centralized systems.
5. Manageability − More effort required for system management.
6. Unpredictability − Unpredictable responses depending on the system organization and
network load.
 Unit-II

Distributed Shared memory

 Distributed shared memory (DSM) is a form of memory architecture where physically
separated memories can be addressed as one logically shared address space. Here, the
term "shared" does not mean that there is a single centralized memory, but that the
address space is "shared" (same physical address on two processors refers to the same
location in memory).
 Primitives for shared memory: –
Read(address)
Write(address , data)
 Distributed Shared Memory (DSM) refers to the shared-memory paradigm applied to
loosely coupled distributed-memory systems.
 Distributed Shared memory paradigm gives the systems illusion of physically shared
memory.
 DSM is basically an abstraction that integrates the local memory of different machines in
a network environment into a single logical entity shared by cooperating processes
executing on multiple sites.
 The shared memory itself exists only virtually. Application programs can use it in the
same way as a traditional virtual memory, except, of course, that processes using it can
run on different machines in parallel. Due to the virtual existence of the shared memory,
DSM is sometimes also referred to as Distributed Shared Virtual Memory (DSVM).
DSM Architecture
 The DSM systems normally have an architecture of the form shown in Figure 5.1. Each
node of the system consists of one or more CPUs and a memory unit. The- nodes are
connected by a high-speed communication network. A simple message-passing system
allows processes on different nodes to exchange messages with each other.
 The DSM abstraction presents a large shared-memory space to the processors of all
nodes. In contrast to the shared physical memory in tightly coupled parallel
architectures, the shared memory of DSM exists only virtually. A software memory-
mapping manager routine in each node maps the local memory onto the shared virtual
memory. To facilitate the mapping operation, the shared-memory space is partitioned
into blocks.
 Data caching is a well-known solution to address memory access latency. The idea of
data caching is used in DSM systems to reduce network latency. That is, the main
memory of individual nodes is used to cache pieces of the shared-memory space. The
memory-mapping manager of each node views its local memory as a big cache of the
shared-memory space for its associated processors. The basic unit of caching is a
memory block.
 When a process on a node accesses some data from a memory block of the shared-
memory space, the local memory-mapping manager takes charge of its request. If the
memory block containing the accessed data is resident in the local memory, the request
is satisfied by supplying the accessed data from the local memory. Otherwise, a network
block fault is generated and the control is passed to the operating system. The operating
system then sends a message to the node on which the desired memory block is located
to get the block. The missing block is migrated from the remote node to the client
process's node and the operating system maps it into the application's address space.
The faulting instruction is then restarted and can now complete. Therefore, the scenario
is that data blocks keep migrating from one node to another on demand but no
communication is visible to the user processes. That is, to the user processes, the system
looks like a tightly coupled shared-memory multiprocessors system in which multiple
processes freely read and write the shared-memory at will, Copies of data cached in
local memory eliminate network traffic for a memory access on cache hit, that is, access
to an address whose data is stored in the cache. Therefore, network traffic is
significantly reduced if applications show a high degree of locality of data accesses.

Types of DSM Architecture:

1.On-Chip Memory:
· Such chips are widely used in appliances cars and even toys.
· CPU portion of the chip has data.
· Address lines directly connect to memory portion.
· it is expensive and complicated to construct chip like this.
2.Bus-Based Multiprocessors:
· connection between cpu and memory is set of parallel wires some holding address of cpu
wants to read or write or for sending or receiving messages
· Network traffic is reduced by using caches with each cpu.
· Algorithms are used to prevent two cpu trying to access same memory simultaneously.
· Having single bus makes it overloaded.

3.Ring-Based Multiprocessors:
· A single address line is partitioned into a private area and shared area.
· Private area is divided up into regions so each machine has a piece for its stack
· Shared area is divided into 32 byte blocks.
· All machines are connected via token passing ring. All components are interconnected
via Memnet device.
· No centralized global memory.
4.Switched Multiprocessors:
· Two approaches can be taken to attack the problem of not enough bandwidth.
· Reduce the amount of communication. E.g. Caching.
· Increase the communication capacity. E.g. Changing topology.
· One method is to build the system as a hierarchy. Build the system as multiple clusters
and connect the clusters using an intercluster bus. As long as most CPUs communicate
primarily within their own cluster, there will be relatively little intercluster traffic. If still
more bandwidth is needed, collect a bus, tree, or grid of clusters together into a
supercluster, and break the system into multiple superclusters.
Design and Implementation issues of DSM
1. Granularity. Granularity refers to the block size of a DSM system, that is, to the unit of
sharing and the unit of data transfer across the network when a network block fault occurs.
Possible units are a few words, a page, or a few pages. Selecting proper block size is an
important part of the design of a DSM system because block size is usually a measure of the
granularity of parallelism explored and the amount of network traffic generated by network
block faults.
2. Structure of shared-memory space. Structure refers to the layout of the shared data in
memory. The structure of the shared-memory space of a DSM system is normally
dependent on the type of applications that the DSM system is intended to support.
3. Memory coherence and access synchronization. In a DSM system that allows replication
of shared data items, copies of shared data items may simultaneously be available in the
main memories of a number of nodes. In this case, the main problem is to solve the memory
coherence problem that deals with the consistency of a piece of shared data lying in the
main memories of two or more nodes.
4. Data location and access. To share data in a DSM system, it should be possible to locate
and retrieve the data accessed by a user process. Therefore, a DSM system must implement
some form of data block locating mechanism in order to service network data block faults to
meet the requirement of the memory coherence semantics being used.
5. Replacement strategy. If the local memory of a node is full, a cache miss at that node
implies not only a fetch of the accessed data block from a remote node but also a
replacement. That is, a data block of the local memory must be replaced by the new data
block. Therefore, a cache replacement strategy is also necessary in the design of a DSM
system.
6. Thrashing. In a DSM system, data blocks migrate between nodes on demand. Therefore,
if two nodes compete for write access to a single data item, the corresponding data block
may be transferred back and forth at such a high rate that no real work can get done. A DSM
system must use a policy to avoid this situation (usually known as thrashing).
 The problem of thrashing may occur when data items in the same data block are
being updated by multiple nodes at the same time, causing large numbers of data block
transfers among the nodes without much progress in the execution of the application.
While a thrashing problem may occur with any block size, it is more likely with larger block
sizes, as different regions in the same block may be updated by processes on different
nodes, causing data block transfers, that are not necessary with smaller block sizes.
7. Heterogeneity. The DSM systems built for homogeneous systems need not address the
heterogeneity issue. However, if die underlying system environment is heterogeneous, the
DSM system must be designed to take care of heterogeneity so that it functions properly
with machines having different architectures.

False sharing- False sharing occurs when two different processes access two unrelated
variables that reside in the same data block (Fig. 5.2). In such a situation, even though the
original variables are not shared, the data block appears to be shared by the two processes.
The larger is the block size, the higher is the probability of false sharing, due to the fact that
the same data block may contain different data structures that are used independently.
Notice that false sharing of a block may lead to a thrashing problem.

Structure of shared-memory space

 Structure defines the abstract view of the shared memory space.
 The structure and granularity of a DSM system are closely related
Three approach
1. No structuring: The shared memory space is simply a linear array of words.
Advantage:
 Choose any suitable page size as the unit of sharing and a fixed grain size may be
used for all application
 Simple and easy to design such a DSM system
2. Structuring by data type:
 The shared memory space is structured either as a collection of variables in the
source language.
  The granularity in such DSM system is an object or a variable.
 DSM system use variable grain size to match the size of the object/variable being
accessed by the application

3. Structuring as a database:
 Structure the shared memory like a database.
 Shared memory space is ordered as an associative memory called tuple space.
 To perform update old data item in the DSM are replaced by new data item.
 Processes select tuples by specifying the number of their fields and their values or
type Access to shared data is non-transparent. Most system they are transparent

Consistency models
 Consistency requirement vary from application to application .
 A consistency model basically refers to the degree of consistency that has to be
maintained for the shared memory data.
 It is defined as a set of rules that application must obey if they want the DSM system to
provide the degree of consistency guaranteed by the consistency model.
 If a system support the stronger consistency model then the weaker consistency model
is automatically supported but the converse is not true.

Types:
1. Strict consistency model
 This is the strongest form of memory coherence having the most stringent consistency
requirement
 Value returned by a read operation on a memory address is always same as the value
written by the most recent write operation to that address
 All writes instantaneously become visible to all processes
 Implementation of the strict consistency model requires the existence of an absolute
global time
 Absolute synchronization of clock of all the nodes of a distributed system is not possible
 Implementation of strict consistency model for a DSM system is practically impossible
 If the three operations read(r1), write(w1), read(r2) are performed on a memory
location in that order Only acceptable ordering for a strictly consistency memory is (r1,
w1, r2)

2. Sequential Consistency model

 Proposed by Lamport [1979]
 A shared memory system is said to support the sequential consistency model if all
processes see the same order
 Exact order of access operations are interleaved does not matter
 If the three operations read(r1), write(w1), read(r2) are performed on a memory
location in that order then any of the orderings (r1, w1, r2), (r1, r2, w1), (w1, r1, r2),
(w1,r2, r1), (r2, r1, w1), (r2, w1, r1) is acceptable provided all processes see the same
ordering.
 The consistency requirement of the sequential consistency model is weaker than that of
the strict consistency model.
 A sequentially consistency memory provide one-copy /single-copy semantics
 sequentially consistency is acceptable by most applications

3. Causal Consistency Model

 Proposed by Hutto and Ahamad (1990)
 All processes see only those memory reference operations in the correct order that are
potentially causally related
 Memory reference operations not related may be seen by different processes in
different order
 Memory reference operation is said to be related to another memory reference
operation if one might have been influenced by the other
 Maintaining dependency graphs for memory access operations

4. Pipelined Random Access Memory Consistency model

 Proposed by Lipton and Sandberg (1988)
 Provides a weaker consistency semantics than the consistency model described so far
Ensures that all write operations performed by a single process are seen by all other
processes in the order in which they were performed
 All write operations performed by a single process are in a pipeline
 Write operations performed by different processes can be seen by different processes in
different order
 If w11 and w12 are two write operations performed by a process P1 in that order, and
w21 and w22 are two write operations performed by a process P2 in that order. A
process P3 may see them in the order [(w11,w12), (w21,w22)] and another process P4
may see them in the order [(w21,w22), (w11,w12)].
 Simple and easy to implement and also has good performance
 PRAM consistency all processes do not agree on the same order of memory reference
operations
5. Processor consistency model
 Proposed by Goodman [1989]
 Very similar to PRAM model with additional restriction of memory coherence
 Memory coherence means that for any memory location all processes agree on the
same order of all write operations performed on the same memory location (no matter
by which process they are performed) are seen by all processes in the same order
 If w12 and w22 are write operations for writing the same memory location x, all
processes must see them in the same order- w12 before w22 or w22 before w12
Processes P3 and P4 must see in the same order, which may be either [(w11,w12),
(w21,w22)] or [(w21,w22), (w11,w12)].

6. Weak consistency model

 Proposed by Dubois [1988] is designed to take advantage of the following two Common
characteristics to many application:
1. It is not necessary to show the change in memory done by every write operation to other
processes eg. when a process executes in a critical section
2. Isolated accesses to shared variable are rare.
 Better performance can be achieved if consistency is enforced on a group of memory
reference operations rather than on individual memory reference operations
 DSM system that support the weak consistency model uses a special variable called a
synchronization variable.
For supporting weak consistency, the following requirements must be met:
1. All accesses to synchronization variables must obey sequential consistency semantics.
2. All previous write operations must be completed everywhere before an access to a
synchronization variable is allowed.
3. All previous accesses to synchronization variables must be completed before access to a
non-synchronization variable is allowed.
 The weak consistency model provides better performance at the cost of putting extra
burden on the programmers.

7. Release consistency model

 Enhancement of weak consistency model
 Use of two synchronization variables
1. Acquire (used to tell the system it is entering CR)
2.Release (used to tell the system it has just exited CR)
 Acquire results in propagating changes made by other nodes to process's node
 Release results in propagating changes made by the process to other nodes

 Barrier defines the end of a phase of execution of a group of concurrently executing

processes
 Barrier can be implemented by using a centralized barrier server
For supporting release consistency, the following requirements must be met:
1. All accesses to acquire and release synchronization variables obey processor consistency
semantics.
2. All previous acquires performed by a process must be completed successfully before the
process is allowed to perform a data access operation on the memory.
3. All previous data access operations performed by a process must be completed
successfully before a release access done by the process is allowed.

THRASHING
Thrashing is said to occur when the system spends a large amount of time transferring
shared data blocks from one node to another, compared to the time spent doing the useful
work of executing application processes. It is a serious performance problem with DSM
systems that allow data blocks to migrate from one node to another.

Thrashing may occur in the following situations:

1. When interleaved data accesses made by processes on two or more nodes causes a data
block to move back and forth from one node to another in quick succession (a ping-pong
effect).
2. When blocks with read-only permissions are repeatedly invalidated soon after they are
replicated.

Such situations indicate poor (node) locality in references. If not properly handled, thrashing
degrades system performance considerably. Therefore, steps must be taken to solve this
problem. The following methods may be used to solve the thrashing problem in DSM
systems:
1. Providing application-controlled locks. Locking data to prevent other nodes from
accessing that data for a short period of time can reduce thrashing. An application-
controlled lock can be associated with each data block to implement this method.
2. Nailing a block to a node for a minimum amount of time Another method to reduce
thrashing is to disallow a block to be taken away from a node until a minimum amount of
time t elapses after its allocation to that node. The time t can either be fixed statically or be
tuned dynamically on the basis of access patterns. The main drawback of this scheme is that
it is very difficult to choose the appropriate value for the time t. If the value is fixed
statically, it is liable to be inappropriate in many cases.
3. Tailoring the coherence algorithm to the shared-data usage patterns- Thrashing can also
be minimized by using different coherence protocols for shared data having different
characteristics.

 Desirable features of good distributed file system

A good distributed file system should have the following features:
1. Transparency
Transparency refers to hiding details from a user. The following types of transparency are
desirable.
i. Structure transparency: Multiple file servers are used to provide better performance,
scalability, and reliability. The multiplicity of file servers should be transparent to the client
of a distributed file system. Clients should not know the number or locations of file servers
or the storage devices instead it should look like a conventional file system offered by a
centralized, time sharing operating system.
ii. Access transparency: Local and remote files should be accessible in the same way. The file
system should automatically locate an accessed file and transport it to the client’s site.
iii. Naming transparency: The name of the file should not reveal the location of the file. The
name of the file must not be changed while moving from one node to another.
iv. Replication transparency: The existence of multiple copies and their locations should be
hidden from the clients where files are replicated on multiple nodes.
2. User mobility
The user should not be forced to work on a specific node but should have the flexibility to
work on different nodes at different times. This can be achieved by automatically bringing
the users environment to the node where the user logs in.
3. Performance
Performance is measured as the average amount of time needed to satisfy client requests,
which includes CPU time plus the time for accessing secondary storage along with network
access time. Explicit file placement decisions should not be needed to increase the
performance of a distributed file system.
4. Simplicity and ease of use: User interface to the file system be simple and number of
commands should be as small as possible. A DFS should be able to support the whole range
of applications.
5. Scalability
A good DFS should cope with an increase of nodes and not cause any disruption of service.
Scalability also includes the system to withstand high service load, accommodate growth of
users and integration of resources.
6. High availability
A distributed file system should continue to function even in partial failures such as a link
failure, a node failure, or a storage device crash. Replicating files at multiple servers can help
achieve availability.
7. High reliability
Probability of loss of stored data should be minimized. System should automatically
generate backup copies of critical files in event of loss.
8. Data integrity
Concurrent access requests from multiple users who are competing to access the file must
be properly synchronized by the use of some form of concurrency control mechanism.
Atomic transactions can also be provided to users by a file system for data integrity.
9. Security
A distributed file system must secure data so that its users are confident of their privacy.
File system should implement mechanisms to protect data that is stored within.
10. Heterogeneity
Distributed file system should allow various types of workstations to participate in sharing
files via distributed file system. Integration of a new type of workstation or storage media
should be designed by a DFS.

File models
Unstructured files
 Simplest model
 File – unstructured sequence of data
 No substructure
 Contents – un interpreted sequence of bytes
 Unix, MS-Dos
 Modern OS used this model because sharing of files is easier
 in compared with structured file model
 Since file has no structure then different applications can
 interpret the contents of files in many different ways.

Structured files
 Rarely used
 File – ordered sequence of records
 Files – different types, different size and different properties
 Record – smallest unit of data that can be accessed

Two categories
Files with non indexed records:
File records is accessed by specifying it’s position within file
For ex. Fifth record from beginning, second record from end

Files with indexed records:

Records have one or more key fields that can be addressed by
specifying values.
File is maintained as B-tree or other suitable data structure or
hash table to locate records quickly.

File attributes
 Information describing that files
 Has name and value
 Contains information such has owner, size, access permission, date of creation, date
of last modification and date of last access
 User can read the value of any attribute but can’t change or modify it
  Maintained and used by directory service because they are subject to different
access control

Mutable files
 Used by most existing os
 Update performed on files overwrites on old contents to produce new contents
 File is represented as a single stored sequence and that is altered by each update
operation

Immutable files
 Cedar files system.
 File cannot be modified once it has been created except to be deleted.
 File versioning approach is used, a new version of file is created when change is made
rather than updating same file.
 In practice storage space may be reduced by keeping only differences rather than
created whole file again.
 Sharing is much easier because it supports caching and replication which eliminates the
problem of keeping multiple consistent copies.
 Suffering from two issues
Increased use of disk space
Increased disk allocation activity
 CFS uses keep parameter as the no. of most current version of file to be retained.

File Accessing models from book

File-sharing semantics
Multiple users may access a shared file simultaneously. An important design issue for any
file system is to define when modifications of file data done by a user are visible to other
users. This is defined by the file-sharing semantics used by the file system.
1. UNIX semantics
Absolute time ordering is enforced on operations which ensure that read operation on a file
sees the effects of all previous write operations performed on that file. Write to an open file
immediately become visible to users accessing the file at the same time.
2. Session semantics
A session is a series of file accesses made between the open and close file operations. The
changes made to a file are made visible only to the client process that opened the session
and is made invisible to the other remote processes that have the same file open
simultaneously. The changes made to the file are available to the remote processes only
after the session is closed.
3. Immutable shared-files semantics
This is based on the use of immutable file model where an immutable file cannot be
modified once it is created. Changes to the file are handled by creating a new updated
version of the file. The semantics allows the file to be shared only in the read-only mode.
With this approach, shared files cannot be shared at all.
4. Transaction-like semantics This is based on the use of transaction mechanism which
ensures that partial changes made to the shared data by a transaction will not be visible to
other concurrently executing transactions until the transaction ends.

A file-caching scheme for a distributed file system contributes to its scalability and reliability
as it is possible to cache remotely located data on a client node. Every distributed file
system use some form of file caching.
The following can be used:
1.Cache Location
Cache location is the place where the cached data is stored. There can be three possible
cache locations
i.Servers main memory:
A cache located in the server’s main memory eliminates the disk access cost on a cache hit
which increases performance compared to no caching.
The reason for keeping locating cache in server’s main memory-
 Easy to implement
 Totally transparent to clients
 Easy to keep the original file and the cached data consistent.
ii.Clients disk:
If cache is located in clients disk it eliminates network access cost but requires disk access
cost on a cache hit. This is slower than having the cache in servers main memory. Having the
cache in server’s main memory is also simpler.
Advantages:
 Provides reliability.
 Large storage capacity.
 Contributes to scalability and reliability.
Disadvantages:
 Does not work if the system is to support diskless workstations.
 Access time is considerably large.
iii.Clients main memory
A cache located in a client’s main memory eliminates both network access cost and disk
access cost. This technique is not preferred to a client’s disk cache when large cache size
and increased reliability of cached data are desired.
Advantages:
 Maximum performance gain.
 Permits workstations to be diskless.
 Contributes to reliability and scalability.
2.Modification propagation
When the cache is located on client’s nodes, a files data may simultaneously be cached on
multiple nodes. It is possible for caches to become inconsistent when the file data is
changed by one of the clients and the corresponding data cached at other nodes are not
changed or discarded.
The modification propagation scheme used has a critical effect on the systems performance
and reliability.
Techniques used include –
i.Write-through scheme
When a cache entry is modified, the new value is immediately sent to the server for
updating the master copy of the file.
Advantage:
 High degree of reliability and suitability for UNIX-like semantics.
 The risk of updated data getting lost in the event of a client crash is low.
Disadvantage:
Poor Write performance.
ii.Delayed-write scheme
To reduce network traffic for writes the delayed-write scheme is used. New data value is
only written to the cache when a entry is modified and all updated cache entries are sent to
the server at a later time.
There are three commonly used delayed-write approaches:
 Write on ejection from cache:
Modified data in cache is sent to server only when the cache-replacement policy has
decided to eject it from client’s cache. This can result in good performance but there can be
a reliability problem since some server data may be outdated for a long time.
 Periodic write:
The cache is scanned periodically and any cached data that has been modified since the last
scan is sent to the server.
 Write on close:
Modification to cached data is sent to the server when the client closes the file. This does
not help much in reducing network traffic for those files that are open for very short periods
or are rarely modified.
Advantages:
Write accesses complete more quickly that result in a performance gain.
Disadvantage:
Reliability can be a problem.
3.Cache validation schemes
The modification propagation policy only specifies when the master copy of a file on the
server node is updated upon modification of a cache entry. It does not tell anything about
when the file data residing in the cache of other nodes is updated. A file data may
simultaneously reside in the cache of multiple nodes. A client’s cache entry becomes stale as
soon as some other client modifies the data corresponding to the cache entry in the master
copy of the file on the server. It becomes necessary to verify if the data cached at a client
node is consistent with the master copy. If not, the cached data must be invalidated and the
updated version of the data must be fetched again from the server.
There are two approaches to verify the validity of cached data:
i.Client-initiated approach
The client contacts the server and checks whether its locally cached data is consistent with
the master copy.
 Checking before every access- This defeats the purpose of caching because the
server needs to be contacted on every access.
 Periodic checking- A check is initiated every fixed interval of time.
 Check on file open- Cache entry is validated on a file open operation.
ii.Server-initiated approach
 A client informs the file server when opening a file, indicating whether a file is being
opened for reading, writing, or both. The file server keeps a record of which client
has which file open and in what mode. The server monitors file usage modes being
used by different clients and reacts whenever it detects a potential for inconsistency.
E.g. if a file is open for reading, other clients may be allowed to open it for reading,
but opening it for writing cannot be allowed. So also, a new client cannot open a file
in any mode if the file is open for writing.
 When a client closes a file, it sends intimation to the server along with any
modifications made to the file. Then the server updates its record of which client has
which file open in which mode.
 When a new client makes a request to open an already open file and if the server
finds that the new open mode conflicts with the already open mode, the server can
deny the request, queue the request, or disable caching by asking all clients having
the file open to remove that file from their caches.

File Replication : High availability is a desirable feature of a good distributed file system and
file replication is the primary mechanism for improving file availability. Replication is a key
strategy for improving reliability, fault tolerance and availability. Therefore duplicating files
on multiple machines improves availability and performance.
Replicated file : A replicated file is a file that has multiple copies, with each copy located on
a separate file server. Each copy of the set of copies that comprises a replicated file is
referred to as replica of the replicated file.
Advantages of file replication from qb
Difference between caching and replication from qb
Multi Copy Update Problem
Maintaining consistency among copies when a replicated file is updated is the major issue of
file system that supports replication of files. Some commonly used approaches to handle
this issue are described below:
1. Read -Only-Replication 2. Read -Any-Write- All Protocol 3. Available –Copies Protocol 4.
Primary-Copy Protocol 5. Quorum-Based Protocol
1. Read- Only- Replication: This approach allows the replication of only immutable files,
since immutable files are used only in the readonly mode, because mutable files cannot be
replicated.  This approach is too restrictive in the sense that it allows the replication of only
immutable files.
2. Read-Any-Write-All Protocol: This approach allows the replication of mutable files. In this
method, a read operation on a replicated file is performed by reading any copy of the file
and write operation by writing to all copies of the file. Some of the lock has to be used to
carryout a write operation. That is, before updating any copy, all copies are locked, then the
they are updated, and finally locks are released to complete write operation. The protocol is
used for implementing UNIX like Semantics  The main problem with this approach is that a
write operation can’t be performed if any of the servers having a copy of the replicated file
is down at a time of write operation.
3.Available-Copies Protocol: this Approach allows the write operation to be carried out
even when some of the servers having a copy of the replicated file are down. In this method
the read operation is performed by reading any available copy, but a write operation is
performed by writing to all available copies. When the server recovers after a failure, it
brings itself up to date by copying from the other servers before accepting any user request.
4.Primary-Copy Protocol: another simple method to solve the multi-copy update problem is
the primary –copy protocol. In this protocol for each replicated file one copy is as the
primary copy and all others are secondary copies. Read operation can be performed using
any copy primary or secondary. Each server having a copy updates its copy either by
receiving notification of changes from the server having the primary copy or by requesting
the updated copy from it.
5. Quorum –Based Protocol: This protocol is capable of handling the network partition
problem and can increase the availability of write operations at the expense of read
operation.
Fault Tolerance
 A system fails when it does not match its promises. An error in a system can lead to a
failure. The cause of an error is called a fault.
 Faults are generally transient, intermittent or permanent. Transient occurs once and
disappears, intermittent fault keep reoccurring and permanent faults continue till
system is repaired.
 Being fault tolerant is related to dependable systems. The dependability includes
availability, reliability, safety and maintainability.
  The ability of a system to continue functioning in the event of partial failure is known
as fault tolerance.
 It is an important goal in distributed system design to construct a system that can
automatically recover from partial failures without affecting overall performance.

The primary file properties that directly influence the ability of a distributed file system to
tolerate faults are as follows:
i. Availability
 This refers to the fraction of time for which the file is available for use. This property
depends on location of the clients and the location of files.
 Example: If a network is partitioned due to a communication failure, a link may be
available to the clients on some nodes but may not be available to clients on other
nodes. Replication is a primary mechanism for improving the availability.
ii. Robustness
 This refers to the power to survive crashes of the storage files and storage decays of
the storage medium on which it is stored. Storage devices implemented using
redundancy techniques are often used to store robust files.
 A robust file may not be available until the faulty component has been recovered.
Robustness is independent of either the location of the file or the location of clients.
iii. Recoverability
 This refers to the ability to roll back to the previous stable and consistent state when
an operation on a file is aborted by the client. Atomic update techniques such as
transaction mechanism are used.

Difference between stateful and stateless server

1) State Information :
 A Stateful server remember client data (state) from one request to the next. Stateful
servers, do store session state. They may, therefore, keep track of which clients have
opened which files, current read and write pointers for files, which files have been
locked by which clients, etc.
 A Stateless server keeps no state information.Stateless file servers do not store any
session state. This means that every client request is treated independently, and not
as a part of a new or existing session.
2) Programming :
 Stateful server is harder to code.
 Stateless server is straightforward to code.
3) Crash recovery :
 Stateful servers have difficult crash recovery due to loss of information.
 Stateless servers can easily recover from failure because there is no state that must
be restored.
4) Information transfer :
  Using a Stateful server, file server, the client can send less data with each request.
 Using a stateless file server, the client must, specify complete file names in each
request specify location for reading or writing re-authenticate for each request.
5) Efficiency
 In Stateful servers efficiency is more because clients do not have to provide full file
information every time they perform an operation
 In Stateless servers efficiency is Less because information needs to be provided
6) Advantages of both Stateful and Stateless servers:
The main advantage of Stateful servers, is that they can provide better performance for
clients because clients do not have to provide full file information every time they perform
an operation, the size of messages to and from the server can be significantly decreased.
Likewise the server can make use of knowledge of access patterns to perform read-ahead
and do other optimizations. Stateful servers can also offer clients extra services such as file
locking, and remember read and write positions.

The main advantage of stateless servers is that they can easily recover from failure. Because
there is no state that must be restored, a failed server can simply restart after a crash and
immediately provide services to clients as though nothing happened. Furthermore, if clients
crash the server is not stuck with abandoned opened or locked files. Another benefit is that
the server implementation remains simple because it does not have to implement the state
accounting associated with opening, closing, and locking of files.
7)Operations
In a Stateful server for byte stream files the following operations take place:
i. Open (filename, mode): This operation opens a file named filename in the specified mode.
An entry for this file in file table is created which maintains file state information. When file
is opened R/W pointer is set to zero and the client receives the file Fid.
ii. Read (Fid, m, buffer): This operation gets m bytes of data from the Fid file into the buffer.
When this operation is executed the client receives m bytes of file data starting from the
byte addressed by R/W pointer and then the pointer is incremented by m.
iii. Write (Fid, m, buffer): When this operation is executed, m bytes of data are taken from
the specified buffer and writes it into the Fid file at byte position which is addressed by the
W/R pointer and then increments the pointer by m.
iv. Seek (Fid, position): This operation changes the value of read-write pointer of the file Fid
to a new value specified as position.
v. Close (Fid): This operation is used to delete file state information of the file Fid from its
file-table.
In a stateless servers For a byte stream file server the operations for a file to be stateless
are:
i. Read (filename, position, m, buffer): For this operation the server returns to the client
with m bytes of data of the file identified as filename and saves it in the buffer. The value of
the bytes is returned to the client and the position for reading is specified as position
parameter.
ii. Write (filename, position, m, buffer): This operation takes m bytes of data from the buffer
and writes it into the file named filename. The position to start writing in the file is specified
by position parameter.

8) Disadvantages
Stateful server – If the server crashes and restarts, the state information it was holding may
be lost and the client may produce inconsistent results – If the client process crashes and
restarts, the server will have inconsistent information about the client.
Stateless server: The stateless service paradigm also suffers from the drawbacks of longer
request messages and slower processing of request. Request messages are longer because
every request must be accompanied with all the necessary parameters to successfully carry
out the desired operation.

Naming
 The naming facility of a distributed operating system enables users and programs to
assign character-string names to objects and subsequently use these names to refer
to those objects.
 The locating facility, which is an integral part of the naming facility, maps an object's
name to the object's location in a distributed system.
 The naming and locating facilities jointly form a naming system that provides the
users with an abstraction of an object that hides the details of how and where an
object is actually located in the network.
 It provides a further level of abstraction when dealing with object replicas. Given an
object name, it returns a set of the locations of the object's replicas.
  The naming system plays a very important role in achieving the goal of location
transparency, facilitating transparent migration and replication of objects, object
sharing.

desirable features of good naming system from qb

Object Locating Mechanism

 Object locating is the process of mapping an object's system-oriented unique identifier
(UID for short) to the replica locations of the object.
 In a distributed system, object locating is only the process of knowing the object's
location, that is, the node on which it is located.
 On the other hand, object accessing involves the process of carrying out the desired
operation (e.g., read, write) on the object. Therefore, the object-accessing operation
starts only after the object-locating operation has been carried out successfully.

Several object-locating mechanisms have been proposed and are being used by various
distributed operating systems.
1. Broadcasting
2. Expanding ring Broadcast
3. Encoding location of object within its UID
4.Searching creator node first and then Broadcasting
5. Using forward location pointers
6. using hint cache and broadcasting

Unit 5
Distributed DataBase

 A distributed database DDB) is a collection of multiple, logically interrelated databases

distributed over a computer network.
 A distributed database is basically a database that is not limited to one system, it is
spread over different sites, i.e, on multiple computers or over a network of computers.
 A distributed database system consists of loosely coupled sites that share no physical
component.
 Database systems run on each site are independent of each other.
A distributed database management system DDBMS) is the software that manages the
DDB and provides an access mechanism that makes this distribution transparent to the
users.

A Distributed Database Management System DDBMS) consists of a single logical database

that is split into a number of fragments. Each fragment is stored on one or more computers
under the control of a separate DBMS, with the computers connected by a communications
network. Each site is capable of independently processing user requests that require access
to local data that is, each site has some degree of local autonomy) and is also capable of
processing data stored on other computers in the network.

Users access the distributed database via applications. Applications are classified as those
that do not require data from other sites local Applications) and those that do require data
from other sites global applications). We require a DDBMS to have at least one global
application.

Features

 It is used to create, retrieve, update and delete distributed databases.

 It synchronizes the database periodically and provides access mechanisms by the
virtue of which the distribution becomes transparent to the users.
 It ensures that the data modified at any site is universally updated.
 It is used in application areas where large volumes of data are processed and
accessed by numerous users simultaneously.
 It is designed for heterogeneous database platforms.
 It maintains secrity and data integrity of the databases.
 Distributed transaction management
 Distributed database recovery

Types:
1. Homogeneous Database:
 In a homogeneous database, all different sites store database identically.
  The operating system, database management system and the data structures used –
all are same at all sites.
 All sites Are aware of each other and agree to cooperate in processing user requests.
 Each site surrenders part of its autonomy in terms of right to change schemas or
software
 Appears to user as a single system
 They’re easy to design and manage.
2. Heterogeneous Database:
 In a heterogeneous distributed database, different sites can use different schema
and software.
 Difference in schema is a major problem for query processing
 Difference in software is a major problem for transaction processing
 Sites may not be aware of each other and may provide only limited facilities for
cooperation in query processing
 translations are required for different sites to communicate.
 Difficult to design and manage

Advantages of Distributed Database over Centralized Database

1. Less danger of a single-point failure. When one of the computers fails, the workload is
picked up by other workstations.
2. Data are also distributed at multiple sites.
3. The end user is able to access any available copy of the data, and an end user's request is
processed by any processor at the data location.
4. Improved communications. Because local sites are smaller and located closer to
customers.
5.Reduced operating costs. It is more costeffective to add workstations to a network than to
update a mainframe system.
6. Faster data access, faster data processing.
7. A distributed database system spreads out the systems workload by processing data at
several sites.

Disadvantages
1. Complexity of management and control.
2. Applications must recognize data location, and they must be able to stitch together data
from various sites.
3. Security concerns
4. Increased storage and infrastructure requirements.
5. Multiple copies of data has to be at different sites, thus an additional disk storage space
will be required.
6. The probability of security lapses increases when data are located at multiple sites.

Distributed multimedia system (DMS)

Multimedia data are – continuous streams of data, e.g. digital audio and video.
A distributed multimedia system (DMS) is an integrated communication, computing, and
information system that enables the processing, management, delivery, and presentation of
synchronized multimedia information with quality-of-service guarantees.

Multimedia applications generate and consume continuous streams of data in real time.
They contain large quantities of audio, video and other time-based data elements, and the
timely processing and delivery of the individual data elements is essential. In distributed
system, data transmission is pre-requisite. So the main topic in distributed multimedia
system is how to transfer multimedia data within the demanded quality. The existing
standards and platforms about the distributed system, such as RM-ODP, CORBA and DCE,
mainly focus on the discrete data transmission. The introduction of multimedia computing
puts a large number of new requirements on distributed system.
Firstly, the distributed multimedia system should be able to provide support for continuous
media types, such as audio, video and animation. The introduction of such continuous
media data to distributed systems demands the need for continuous data transfers over
relatively long periods of time. For example, playing a video from a remote website implies
that the timeliness of such media transmission must be maintained in the course of the
continuous media presentation.
The second requirement of distributed multimedia applications is the need for sophisticated
quality of service (QoS) management. In most traditional computing environments, requests
for a particular service are either met or ignored. But in multimedia system, there are more
contents, which can be classified into static QoS management and dynamic QoS
management.
Yet another requirement of distributed multimedia applications is the need for a rich set of
real-time synchronization mechanisms about continuous media transmission. Such real-time
synchronizations can be divided into two categories: intra-media synchronization and inter-
media synchronization.
A further requirement is to support multiparty communications. Many distributed
multimedia applications are concerned with interactions between dispersed groups of
users, for example, a remote conference application. So it is important for distributed
multimedia system to support multiparty communication.

Characteristics of multimedia data

1. Continuous
Referring to video and audio data as continuous. Refer to the user’s view of the data.
Internally, continous media are represented as sequences of discrete values that replace
each other over time.
For Example:
• The value of an image array is replaced 25 times per second to give the impression of a
TV-quality view of moving scene.
• A Sound amplitude value is replaced 8000 times per second to convey telephone-quality
speech.
2. Time based
• Multimedia streams are said to be time-based because timed data elements in audio
and video streams define the content of the stream.
• The systems that support multimedia applications need to preserve the timing when
they handle continous data.
3. Bulky
• Multimedia streams are often bulky. Hence systems that support multimedia
applications need to move data with greater throughput than conventional systems.
• Example:
 • A standard video stream requires more than 120Mbps, which exceeds the
capacity of a 100Mbps Ethernet network.
Compression can reduce bandwidth requirements by factors between 10 and 100, but the
timing requirements of continuous data are unaffected.
• This resulted in formats
• GIF,TIFF,JPEG for images
• MPEG-1,MPEG-2,MPEG-4 for video sequences.
• Although the use of compressed video and audio data reduces bandwidth
requirements in communication networks, it imposes substantial additional loads on
processing resources at the source and destination.

Quality of Service (QoS)

 DMMS are real-time systems as data must be delivered on time
 Not critical – Some flexibility exists
 Loss is acceptable when resync is possible.
 “Acceptable” service is measured by:
 Bandwidth (Throughput)
 Latency (Access time)
 Data Loss Rate (Acceptable loss ratio)
QoS Management
 “QoS Management”
 Process of managing resources to meet the Acceptable service criteria.
 Resources include:
 CPU / processing power
 Network bandwidth
 Buffer memory(on both ends)
 Disk bandwidth
 Other factors affecting communication
Why do we need QoS?
 As multimedia becomes more widespread, strain on network increases!
 Networks provide insufficient QoS for distribution of multimedia.
 Ethernet (wired or wireless) is best effort
 Collisions, data loss, congestion, etc.
 For some multimedia applications, synchronization is vital.

QoS Managers
 Software that runs on network nodes which have two main functions:
 QoS negotiation: get requirements from apps and checks feasibility versus
available resources.
 Admission control: If negotiation succeeds, provides a "resource contract"
that guarantees reservation of resources for a certain time.
Ways to achieve QoS
 Buffering (on both ends)
 Compression
 More load on the nodes, but that is okay
 Bandwidth Reservation
 Resource Scheduling
 Traffic Shaping
 Flow Specifications
 Stream Adaptation

Quality of service negotiation

• Resource requirements specification
–bandwidth
• The rate at which a multimedia stream flows
– Latency
• The time required for an individual data element to The time required for an individual
data element to move through a stream from the source to the destination
• jitter
– Loss rate
Data loss due to unmet resource requirements
• A rate of data loss that can be accepted Eg 1%

Amoeba
The Amoeba distributed operating system project is a research effort aimed at
understanding how to connect computers together in a seemless way.
• Amoeba is an OS that performs all the standard functions of any OS, but it performs
them with a collection of machines.
• One of the main goals of the Amoeba development team was to design a transparent
distributed system that allows users to log into the system as a whole.
• Amoeba is also a parallel system.
• On an Amoeba system, a single program or command can use multiple processors to
increase performance.
• Special development tools have been developed for an Amoeba environment that take
advantage of the inherent parallelism.
• When a user logs into the Amoeba system that they can access the entire system, and
are not limited to only operations on their home machine.
• The Amoeba architecture is designed as a collection of micro-kernels.
• Amoeba implements a standard distributed client / server model, where user processes
and applications (the clients) communicate with servers that perform the kernel
operations.
• An Amoeba system consists of four principle components: user workstations, pool
processors, specialized servers, and gateways.

Its origin
• Amoeba was originally designed and implemented at the Vrije University in
Amsterdam (the Netherlands) in 1981.
• Now, it is being jointly developed there and at the Center for Mathematics and
Computer Science, also in Amsterdam.
• Currently used in various EU countries
• Built from the ground up. UNIX emulation added later
•
Four basic design goals were apparent in Amoeba: Distribution, Parallelism, Transparency,
and Performance

The Amoeba System Architecture

 Designed with two assumptions about the hardware in mind:

1. Systems will have a very large number of CPUs.
2. Each CPU will have tens of megabytes of memory
 All the computing power is located in one or more processor pools
 Processor pool
o Consists of a substantial number of CPUs, each with its own local memory and network
connection
o The CPUs in a pool can be of different architectures like 680x0, 386, and SPARC machines
o Designed to deal with multiple architectures and heterogeneous systems
o When a user types a command, the operating system dynamically chooses one or more
processors on which to run that command
o If there is a shortage of pool processors, individual processors are timeshared, with new
processes being assigned to the most lightly loaded CPUs
 Terminal o It is through the terminal that the user accesses the system o A typical
Amoeba terminal is an X terminal, with a large screen and a mouse
 Specialized servers
o Example: File servers run on a separate processor
o Servers provide services.
 A service is an abstract definition of what the server is prepared to do for its clients.
The Amoeba Microkernel
 The Amoeba microkemel runs on all machines in the system.
 The same kernel can be used on the pool processors, the terminals (assuming that they
are computers, rather than X terminals), and the specialized servers. The microkernel has
four primary functions:
1. Manage processes and threads. 2. Provide low-level memory management support. 3.
Support communication. 4. Handle low-level I/O.

Unit 4
Load Balancing

 In every distributed system there is always a possibility that some nodes are heavily
loaded while some are lightly loaded or are even idle.
Load balancing is a technique in which workload is distributed across multiple computers
that are connected to a network and maybe distributed across the globe to get optimal
resource utilization, minimum time delay, maximize throughput and avoid overloading
of any single node.
A node can be identified by their current load as-
Heavily loaded: Enough jobs are waiting for execution.
Lightly loaded: less jobs are waiting execution
Idle: no jobs are executing on the node
The basic aim is to make every processor equally bussy and to finish the task approximately
at the same time.
Types of load balancing algorithm

Static versus Dynamic:

 Static load balancing algorithms allocate the tasks based on the average load behaviour
of the system.
 Static algorithms ignore the current state or load of the nodes in the system.
 The advantage of this sort of algorithm is the simplicity in terms of both implementation
as well as overhead, since there is no need to constantly monitor the workstations for
performance statistics.
 Static algorithms only work well when there is not much variation in the load on the
workstations.

 Dynamic load balancing algorithms make changes to the distribution of work among
workstations at run-time; they use current or recent load information when making
distribution decisions.
 Dynamic load balancing algorithms can provide a significant improvement in
performance over static algorithms.
 However, this comes at the additional cost of collecting and maintaining load
information, so it is important to keep these overheads within reasonable limits

Load-balancing approach Type of static load-balancing algorithms

Deterministic versus Probabilistic
 Deterministic algorithms use the information about the properties of the nodes and the
characteristic of processes to be scheduled.
 Deterministic approach is difficult to optimize.
 Probabilistic algorithms use information of static attributes of the system (e.g. number
of nodes, processing capability, topology) to formulate simple process placement rules
 Probabilistic approach has poor performance
Load-balancing approach Type of dynamic load-balancing algorithms
Centralized versus Distributed
 Centralized approach collects information to server node and makes assignment
decision.
 Centralized algorithms can make efficient decisions, have lower fault-tolerance
 Distributed approach contains entities to make decisions on a predefined set of nodes .
 Distributed algorithms avoid the bottleneck of collecting state information and react
faster
Load-balancing approach Type of distributed load-balancing algorithms
Cooperative versus Non-cooperative
In Non-cooperative algorithms entities act as autonomous ones and make scheduling
decisions independently from other entities
In Cooperative algorithms distributed entities cooperate with each other Cooperative
algorithms are more complex and involve larger overhead Stability of Cooperative
algorithms are better

Issues in designing Load-balancing algorithms

i. Load estimation policy for Load-balancing algorithms

 The first issue in a load-balancing algorithm is to decide which method to use to
estimate the workload of a particular node.
 A nodes workload can be estimated based on some measurable parameters below:
1. Total number of processes on the node.
2. Resource demands of these processes.
3. Instruction mixes of these processes.
4. Architecture and speed of the node’s processor.

ii.Process transfer policy for Load-balancing algorithms

 The idea of using this policy is to transfer processes from heavily loaded nodes to
lightly loaded nodes.
 Most of the algorithms use the threshold policy to decide whether the node is
lightly-loaded or heavily-loaded. Threshold value is a limiting value of the workload
of node which can be determined by: Static policy: Predefined threshold value for
each node depending on processing capability. Dynamic policy: threshold value is
calculated from average workload and a predefined constant.
 Below threshold value node accepts processes to execute, above threshold value
node tries to transfer processes to a lightly-loaded node.
 Single-threshold policy may lead to unstable algorithm because underloaded node
could turn to be overloaded right after a process migration.
 To reduce instability double-threshold policy has been proposed which is also known
as high-low policy.
iii.Location policy for Load-balancing algorithms
 The selection of destinations node for process execution is made by the location
policy of a scheduling algorithm.
 The policies used can be:
Threshold method
 This policy selects a random node and checks whether the node is able to receive the
process then it transfers the process. If node rejects the transfer another node is
selected randomly. This continues until probe limit is reached. Shortest method
 In this M distinct nodes are chosen at random and each is polled to determine its
load. The process is transferred to the node having the minimum value unless its
 workload value prohibits it from accepting the process. To improve this it is
necessary to discontinue probing whenever a node with zero load is encountered.
Bidding method
 In this method nodes contain managers to send processes and contractors to receive
processes.
 Managers broadcast a request for bid and contractors respond with bids where the
manager selects the best offer.
 The winning contractor is notified and asked whether it accepts the process for
execution or not. A contractor is never forced to accept remote process.
Pairing
 The pairing policy is used to reduce the variance of load only between nodes of the
system.
 Each node asks some randomly chosen node to form a pair with it. If it receives a
rejection it randomly selects another node and tries to pair again.
 Two nodes that differ greatly in load are temporarily paired with each other and
migration starts. The pair is broken as soon as the migration is over. A node only tries
to find a partner if it has at least two processes.

iv. State information exchange policy for Load-balancing algorithms

 Dynamic policies require frequent exchange of state information among the systems.
 These extra messages arise two opposite impacts one is that it increasing the
number of messages gives more accurate scheduling decision and the other is it
increasing the number of messages raises the queuing time of messages.
State information policies that can be used are:
Periodic broadcast
 Each node broadcasts its state information after the elapse of every Tunits of time
 The problems caused are heavy traffic, poor scalability.
Broadcast when state changes
 This method avoids fruitless message exchange by broadcasting the state only when
a process arrives or departures.
 Further improvement that can be done is to broadcast only when state switches to
another region.
On-demand exchange
 In this method a node broadcasts a State-Information-Request message when its
state switches from normal to either under-loaded or overloaded region.
 On receiving this message other nodes reply with their own state information to the
requesting node
 Further improvement can be that only those nodes reply which are useful to the
requesting node and use of State Information Request.
Exchange by polling
  The polling method overcomes poor scalability that comes from broadcast messages.
There is no need for a node to exchange its state information.
 The partner node is searched by polling the other nodes on by one until poll limit is
reached.
v. Priority assignment policy for Load-balancing algorithms
In a distributed operating system that support process migration, a priority assignment rule
for scheduling the local and remote process of a node should be planned.
One of the following priority assignment rules may be used:
1. Selfish priority assignment rule
o In this the local processes are given higher priority than remote processes.
o This rule has the worst response time performance of the three policies due
to poor performing processes.
o Best response time performance is achieved for local processes.
2. Altruistic priority assignment rule
o Remote processes are given higher priority than local processes in this rule.
o It has the best response time performance of the three policies.
o Remote process incur lower delays than local processes as local processes are
treated as principal while remote processes are secondary workload.
3. Intermediate priority assignment rule
o Priority in this rule is decided depending on number of local and remote
processes on a node.
o When the number of local processes is greater or equal to the number of
remote processes than local processes are given higher priority or else
remote processes are given higher priority than local processes.
o Performance of this rule is between the two above policies. Overall response
time performance is close to altruistic policy.

vi. Migration limiting policy for Load-balancing algorithms:

This policy determines the total number of times a process can migrate.
One of the following two policies may be used-
a.Uncontrolled: A remote process arriving at a node is treated just as a process originating
at a node due to which a process may be migrated any number of times.
b.Controlled: This avoids the instability of the uncontrolled policy and uses a migration
count parameter to fix a limit on the number of time a process that can migrate.
A long process may be allowed to migrate more times compares to short process.

Components of load distributing algorithms

Transfer policy: First of all the state of the different machines is determined by calculating
it’s workload. A transfer policy determines whether a machine is in a suitable state to
participate in a task transfer, either as a sender or a receiver. For example, a heavily loaded
machine could try to start process migration when its load index exceeds a certain
threshold.
Selection policy: This policy determines which task should be transferred. Once the transfer
policy decides that a machine is in a heavily-loaded state, the selection policy selects a task
for transferring. Selection policies can be categorized into two policies: preemptive and non-
preemptive. A preemptive policy selects a partially executed task. As such, a preemptive
policy should also transfer the task state which can be very large or complex. Thus,
transferring operation is expensive. A non-preemptive policy selects only tasks that have not
begun execution and, hence, it does not require transferring the state of task.
Location policy: The objective of this policy is to find a suitable transfer partner for a
machine, once the transfer policy has decided that the machine is a heavily-loaded state or
lightly-loaded one. Common location policies include: random selection, dynamic selection,
and state polling.
Information policy: This policy determines when the information about the state of other
machines should be collected, from where it has to be collected, and what information is to
be collected.

TASK MIGRATION
Introduction
 Singhal and Shivaratri define process/task migration as the transfer of partially
executed tasks to another node in a distributed system - in other words, preemptive
task transfer. Some references to task migration include the transfer of processes
before execution begins, but the most difficult issues are those related to
preemption.
 Terminology:
o Task placement: non-preemptive transfer of process that has never run
o Task migration: preemptive transfer of process that has been executed
o Home node: site where the process originates
o Foreign process: process executing on a node other than its home node
o Freezing: when a process is migrated, its execution is interrupted (frozen) for
the time it takes to move the process to another site.
 Migration is useful for several reasons:
o load distribution, to equalize workload due to
 transient periods of high load at some network nodes (transfer
processes from temporarily overloaded node to another node)
 or in a system where process origination is always unbalanced (a few
workstations consistently generate many processes )
o to return a workstation to its owner. (migrate a foreign process back to its
home node when owner returns)
 o to improve communication (processes that communicate frequently can be
moved to the same node; processes that access resources at a remote site
may be moved to that site)
 Two steps in task migration:
o State transfer: collect all information crucial to process execution and
transfer to another machine
 Process control block contains register contents, memory map
information, etc.
 Process address space includes stack, heap, plus virtual pages
currently in memory
At some point during state collection, the process must be frozen
o Unfreeze: after installing the process state at the new site, the process is put
in the Ready queue to be scheduled

Issues in Task Migration

 State Transfer: Issues to consider here include
o Cost in processor time, network bandwidth, etc.: When a process is moved to
another node, it is frozen until the transfer is complete. There is the cost of a
complete context switch, plus transfer, plus possible affect on other
processes that might be affected. (Processes that interact with the migrating
process may timeout during the interval when it is frozen, and thus could be
aborted)
o Residual dependencies: These are resources that the original host node must
maintain on behalf of the migrated process. For example, a process may
transfer pages in virtual memory only as they are referenced; the original
host may have to forward messages directed to the process at its original
site.
 Location Transparency: Users aren't required to know where a task is executed;
there should be no affect on the process. Process names, file names, etc., must be
independent of the host machine. A uniform name space is important to allow the
process to maintain access to system resources, to continue to be able to
communicate with other processes, etc.
 Structure of the Migration Mechanism: Singhal and Shivaratri emphasize the
separation of policy from mechanism. Policy decides when/where/why transfer to
be done (see discussion of policies earlier) while mechanism is the act of collecting
state, sending it elsewhere, etc. As always, there are benefits to separating the two:
for example, policies can be changed without affecting mechanisms.
 Performance: This is the major drawback to any kind of dynamic task migration
facility.
Deadlock I distributed Systems
A deadlock is a condition in a system where a set of processes (or threads) have requests for
resources that can never be satisfied. Essentially, a process cannot proceed because it needs
to obtain a resource held by another process but it itself is holding a resource that the other
process needs.
Deadlocks in distributed systems are similar to deadlocks in single-processor systems, only
worse. They are harder to avoid, prevent, or even detect, and harder to cure when tracked
down because all the relevant information is scattered over many machines. In some
systems, such as distributed data base systems, they can be extremely serious, so it is
important to understand how they differ from ordinary deadlocks and what can be done
about them.
Some people make a distinction between two kinds of distributed deadlocks:
communication deadlocks and resource deadlocks. A communication deadlock occurs, for
example, when process A is trying to send a message to process B, which in turn is trying to
send one to process C, which is trying to send one to A .There are various scenarios in which
this situation leads to deadlock, such as no buffers being available. A resource deadlock
occurs when processes are fighting over exclusive access to I/O devices, files, locks, or other
resources.

Four conditions have to be met for a deadlock to occur in a system:

1. Mutual exclusion A resource can be held by at most one process.
2. Hold and wait: Processes that already hold resources is waiting for another resource.
3. Non-preemption: A resource, once granted, cannot be taken away.
4. Circular wait: Two or more processes are waiting for resources held by one of the
other processes.

Deadlock Handling Strategies

1. Deadlock Prevention: Resources are granted to the requesting processes in such a way
that there is no chance of deadlock ( Vaccination). For example, allocating the resources
requested if all available. Else wait for all. [ So no hold and wait condition holds in that
case.]
We saw that mutual-exclusion, hold-and-wait, no-preemption, and circular-wait are the four
necessary conditions for a deadlock to occur in a system. Therefore, if we can somehow
ensure that at least one of these conditions is never satisfied, deadlocks will be impossible.
Based on this idea, there are three important deadlock-prevention methods- collective
requests, ordered requests, and preemption. The first one denies the hold-and- wait
condition, the second one denies the circular-wait condition, and the third one denies the
no-preemption condition.

2. Deadlock Avoidance: Resources are granted as and when requested by the processes
provided the resulting system is safe. The system state is said to be safe, if there exist at
 least one sequence of execution for all the process such that all of them can run to
completion without getting into deadlock situation.
Deadlock avoidance methods use some advance knowledge of the resource usage of
processes to predict the future state of the system for avoiding allocations that can
eventually lead to a deadlock. Deadlock avoidance algorithms are usually in the following
steps:
1. When a process requests for a resource, even if the resource is available for allocation, it
is not immediately allocated to the process. Rather, the system simply assumes that the
request is granted.
2. With the assumption made in step 1and advance knowledge of the resource usage of
processes, the system performs some analysis to decide whether granting the process's
request is safe or unsafe.
3. The resource is allocated to the process only when the analysis of step 2 shows that it is
safe to do so; otherwise the request is deferred.

3. Deadlock Detection and Recovery: In this strategy, the resources are allocated to the
processes as and when requested. However, the deadlock is detected by deadlock
detection algorithm. If deadlock is detected, the system recovers from it by aborting
one or more deadlocked processes.
In this approach for deadlock handling, the system does not make any attempt to prevent
deadlocks and allows processes to request resources and to wait for each other in an
uncontrolled manner. Rather, it uses an algorithm that keeps examining the state of the
system to determine whether a deadlock has occurred. When a deadlock is detected, the
system takes some action to recover from the deadlock.

Distributed deadlock detection algorithms can be divided into four classes:

1. Path-Pushing Algorithms: In path-pushing algorithms, distributed deadlocks are detected

by maintaining an explicit global WFG.
The basic idea is to build a global WFG for each site of the distributed system. In this class of
algorithms, at each site whenever deadlock computation is performed, it sends its local
WFG to all the neighboring sites.
After the local data structure of each site is updated, this updated WFG is then passed along
to other sites, and the procedure is repeated until some site has a sufficiently complete
picture of the global state to announce deadlock or to establish that no deadlocks are
present.
This feature of sending around the paths of global WFG has led to the term path-pushing
algorithms.
2. Edge-Chasing Algorithms In an edge-chasing algorithm, the presence of a cycle in a
distributed graph structure is be verified by propagating special messages called probes,
along the edges of the graph. These probe messages are different than the request and
reply messages. The formation of cycle can be deleted by a site if it receives the matching
probe sent by it previously. Whenever a process that is executing receives a probe message,
it discards this message and continues. Only blocked processes propagate probe messages
along their outgoing edges.
Main advantage of edge-chasing algorithms is that probes are fixed size messages which is
normally very short.
3. Diffusing Computations Based Algorithms
In diffusion computation based distributed deadlock detection algorithms, deadlock
detection computation is diffused through the WFG of the system. These algorithms make
use of echo algorithms to detect deadlocks. This computation is superimposed on the
underlying distributed computation. If this computation terminates, the initiator declares a
deadlock global state detection.
4. Global State Detection Based Algorithms
Global state detection based deadlock detection algorithms exploit the following facts:
1 A consistent snapshot of a distributed system can be obtained without freezing the
underlying computation and
2 If a stable property holds in the system before the snapshot collection is initiated, this
property will still hold in the snapshot.
Therefore, distributed deadlocks can be detected by taking a snapshot of the system and
examining it for the condition of a deadlock.

i.WFG-Based Distributed Algorithm for Deadlock Detection

 In this algorithm each site maintains its own local WFG but for external processes a
modified form of WGF is used. In this an extra node Px is added to the local WFG of
each site and this node is connected to the WFG if an edge (Pi,Px) is added if process
Pi is waiting for resource in another site and if Pjis a process of another site waiting
for a resource being held by process of this site.
 Advantages: similar to centralized approach
 Disadvantage: overhead of unnecessary message transfer, Duplication of deadlock
detection jobs.
ii.Probe-Based Distributed Algorithm for Deadlock Detection
 This algorithm is also known as Chandy-Misra-Hass algorithm is considered to be the
best algorithm for detecting global deadlocks in distributed systems and is based on
edge-chasing.
 The algorithm allows a process to request for multiple resources at a time.
 If a process makes a request for a resource which fails or times out, the process
generates a probe message and sends it to each of the processes holding one or more of
its requested resources.
 Each probe message contains the following information:
1. the id of the process that is blocked (the one that initiates the probe message);
2. the id of the process is sending this particular version of the probe message; and
3. the id of the process that should receive this probe message.
 When a process receives a probe message, it checks to see if it is also waiting for
resources.
 If not, it is currently using the needed resource and will eventually finish and release the
resource.
 If it is waiting for resources, it passes on the probe message to all processes it knows to
be holding resources it has itself requested.
 The process first modifies the probe message, changing the sender and receiver ids.
 If a process receives a probe message that it recognizes as having initiated, it knows
there is a cycle in the system and thus, deadlock.
 The following example is based on the same data used in the Silberschatz-Galvin
algorithm example. In this case P1 initiates the probe message, so that all the messages
shown have P1 as the initiator. When the probe message is received by process P3, it
modifies it and sends it to two more processes. Eventually, the probe message returns
to process P1. Deadlock!


 Advantages: Overhead is low, simple to implement, false deadlocks not detected.

Issues in Deadlock Detection and resolutions from qb