DISTRIBUTED

OPERATING SYSTEMS

MCS-041
Block-3
Unit-2(a)
 Topics to be covered

 Distributed Systems

 Key Features and Advantages of a Distributed System

Advantages of Distributed Systems Over Centralized Systems

Advantages of Distributed Systems over Isolated PC’s

Disadvantages of Distributed Systems

 Design Goals of Distributed Systems

Concurrency
Scalability
 Topics to be covered
Openness
Fault Tolerance
Privacy and Authentication
Transparency

 Design Issues Involved in Distributed Systems

Naming
Communication
Software Structure
Workload Allocation
Consistency Maintenance
Lamport’s Scheme of Ordering of Events
 Topics to be covered

 Distributed System Structure

Application Model 1: Client Server

Application Model 2: Distributed Objects

Application Model 3: Distributed Shared Memory

 Mutual Exclusion in Distributed Systems

Mutual Exclusion Servers

Token Based Mutual Exclusion

Lamport’s Bakery Algorithm

Ricart and Agrawala’s Mutual Exclusion Algorithm

 Topics to be covered

 Remote Procedure Calls

How RPC Works?

Remote Procedure Calling Mechanism

Implementation of RPC

Considerations for Usage

Limitations

 Other Middleware Technologies

 Distributed Systems

Multiprocessor systems have more than one processing unit sharing

memory/peripheral devices. They have greater computing power, and higher

reliability. Multiprocessor systems are classified into two:

• Tightly-coupled: Each processor is assigned a specific duty but processors

work in close association, possibly sharing one memory module.

• Loosely-coupled (distributed): Each processor has its own memory and

copy of the OS.

 Distributed Systems
 A distributed computer system is a loosely coupled collection of

autonomous computers connected by a network using system software to

produce a single integrated computing environment.

 A distributed operating system differs from a network of machines each

supporting a network operating system in only one way.

 With distributed operating systems, the entire system is itself distributed

across the network.

 Key Features of Distributed Systems

 They are Loosely coupled

remote access is many times slower than local access

 Nodes are autonomous

workstation resources are managed locally

 Network connections using system software

remote access requires explicit message passing between

nodes
 Key Features of Distributed Systems

Messages are CPU to CPU

Protocols for reliability, flow control, failure detection, etc.,

implemented in software

The only way two nodes can communicate is by sending and

receiving network messages-this differs from a hardware

approach in which hardware signalling can be used for flow

control or failure detection.

 Advantages of Distributed Systems
over Centralized Systems
• Better price/performance than mainframes

• More computing power

sum of the computing power of the processors in the distributed

system may be greater than any single processor available (parallel

processing)

• Some applications are inherently distributed

• Improved reliability because system can survive crash of one processor

• Incremental growth can be achieved by adding one processor at a time

• Shared ownership facilitated.

 Advantages of Distributed Systems
over Isolated PCs

• Shared utilization of resources.

• Communication.

• Better performance and flexibility than isolated personal computers.

• Simpler maintenance if compared with individual PC’s.

 Disadvantages of Distributed Systems
• Network performance parameters.

• Latency: Delay that occurs after a send operation is executed before data starts to

arrive at the destination computer.

• Data Transfer Rate: Speed at which data can be transferred between two computers

once transmission has begun.

• Total network bandwidth: Total volume of traffic that can be transferred across the

network in a give time.

• Dependency on reliability of the underlying network.

• Higher security risk due to more possible access points for intruders and possible

communication with insecure systems.

 Design Goals of Distributed Systems

Design Goals

Fault Privacy and

Concurrency Scalability Openness Transparency.
Tolerance Authentication
 Design Issues involved in
Distributed Systems

Design issues to be considered for distributed systems are:

a) Naming

b) Communication

c) Software Structure

d) Workload Allocation

e) Consistency Maintenance
 Naming
• A name is a string of characters used to identify and locate a distributed resource.

• An identifier is a special kind of name that is used directly by the computer to access

the resource.

For example the identifier for a Unix server would include at least (1) an IP address

and (2) a port number. The IP address is used to find the node that runs the server

and the port number identifies the server process on that node.

• Resolution is the process of turning a name into an identifier. Resolution is

performed by a Name Server. It is also called “binding” (as in binding a name to a

distributed service).
 Communication & Software
Structures
Communication

• Getting different processes to talk to each other

• Messages

• Remote method invocation.

Software Structures

• The main issues are to choose a software structure that supports our goals,

particularly the goal of openness.

• We thus want structures that promote extensibility and otherwise make it easy to

program the system.

 Workload Allocation

• The key issue is load balancing: The allocation of the network workload such that

network resources (e.g., CPUs, memory, and disks) are used efficiently.

For CPUs, there are two key approaches. They are:

a) Processor Pools

b) Idle Workstations
 Consistency Maintenance
The final issue is consistency. There are four key aspects of consistency:

Atomicity

Coherence

Failure Consistency

Clock Consistency
 Distributed System Structure

There are three main alternative ways to structure a distributed application. The

three distributed system application models are:

• Client / Server (and RPC)

• Distributed objects

• Distributed shared memory.

 Application Model 1: Client Server
 A designated node exports a “service”; this node is called the “server”.

 Nodes that import and use the service are called “clients”.

 Clients communicate with servers using a “request-response” protocol.

 Request-response differs from other protocols.

 Peer-to-peer protocols don’t have a designated server.

 Streaming protocols such as TCP/IP work differently as we will see a couple of

classes from now.

 Application interface can be either send/receive or RPC

Application Model 1: Client Server
 Application Model 2: Distributed
Objects
 Similar to RPC-based client-server.

 Language-level objects (e.g., C++, Java, Smalltalk) are used to encapsulate data

and functions of a distributed service.

 Objects can reside in either the memory of a client or a server.

 Clients communicate with servers through objects that they “share” with the server.

 There are two main advantages of Distributed Objects over RPC:

 objects hide even more of the details of distribution than RPC (more next week)

 Objects allow clients and servers to communicate using in two different ways:

function shipping (like RPC) and data shipping.

Application Model 2: Distributed
Objects
 Application Model 3: Distributed
Shared Memory

 Usually used for peer-to-peer communication instead of client-server.

 Clients communicate with each other through shared variables.
 The system implements the illusion of shared memory and translates accesses
to shared data into the appropriate messages.
 To a program, the distributed system looks just like a shared-memory
multiprocessor.
 The advantage is that it is really easy to program: hides all of the details of
distribution.
 The disadvantage is that it often hides too much.
 Another disadvantage is that it is very complicated to implement a distributed-
shared memory system that works correctly and performs well.
Application Model 3: Distributed
Shared Memory
 Mutual Exclusion in Distributed
Systems

When all processes sharing a resource are on the same machine, mutual

exclusion is easily assured by the use of a semaphore, spin-lock or other similar

shared abstraction. When the processes involved are on different machines,

however, mutual exclusion becomes more difficult.

 Mutual Exclusion Servers
In the printer example being used here, the problem of storage space in the spooler

typically becomes acute with graphics printers. In such a context, it is desirable to block

an applications process until the printer is ready to accept data from that applications

process, and then let that process directly deliver data to the printer. For example, an

applications process may be coded as follows:

Send request for permission to the spooler

Await reply giving permission to print
Loop
send data directly to printer
End Loop
Send notice to spooler that printing is done

If all users of the spooler use this protocol, the spooler is no longer serving as a spooler,
it is merely serving as a mutual exclusion mechanism
 Token Based Mutual Exclusion
One alternative to the mutual-exclusion server is to arrange the competing processes in

a ring and let them exchange a token. If a process receives the token and does not need

exclusive use of the resource, it must pass the token on to the next process in the ring. If

a process needs exclusive use of the resource, it waits for the token and then holds it

until it is done with the resource, at which point it puts the token back in circulation.

This is the exact software analog of a token ring network. In a token ring network, only

one process at a time may transmit, and the circulating token is used to assure this.
 Token Based Mutual Exclusion
• Token-based solution: processes share a special message known as a

token

– Token holder has right to access shared resource

– Wait for/ask for (depending on algorithm) token; enter Critical Section

when it is obtained, pass to another process on exit or hold until

requested (depending on algorithm)

– If a process receives the token and doesn’t need it, just pass it on.
 Token Based Mutual Exclusion

• Advantages:

– Starvation can be avoided by efficient organization of the processes

– Deadlock is also avoidable

• Disadvantage: token loss

– Must initiate a cooperative procedure to recreate the token

– Must ensure that only one token is created!

 Lamport's Bakery Algorithm
Lamport envisioned a bakery with a numbering machine at its entrance so each customer is given
a unique number. Numbers increase by one as customers enter the store. A global counter
displays the number of the customer that is currently being served. All other customers must wait
in a queue until the baker finishes serving the current customer and the next number is displayed.
When the customer is done shopping and has disposed of his or her number, the clerk increments
the number, allowing the next customer to be served. That customer must draw another number
from the numbering machine in order to shop again.

According to the analogy, the "customers" are threads, identified by the letter i, obtained from a
global variable. Due to the limitations of computer architecture, some parts of
Lamport's analogy need slight modification. It is possible that more than one thread will get the
same number when they request it; this cannot be avoided. Therefore, it is assumed that the
thread identifier i is also a priority. A lower value of i means a higher priority and threads with
higher priority will enter the critical section first.
 Lamport's Bakery Algorithm
Lamport’s Bakery Algorithm provides a decentralised implementation of the “take a
number” idea. As originally formulated, this requires that each competing process
share access to an array, but later distributed algorithms have eliminated this shared
data structure. Here is the original formulation:
For each process, i, there are two values, C[i] and N[i], giving the status of process I
and the number it has picked. In more detail:
Ricart and Agrawala's Mutual
Exclusion Algorithm
Ricart and Agrawala's Mutual
Exclusion Algorithm
Ricart and Agrawala's Mutual
Exclusion Algorithm
Ricart and Agrawala's Mutual
Exclusion Algorithm
To be Continue in next session….