Distributed Operating System

Mahesh Goyani
Assistant Professor,
L D College of Engineering
Ahmedabad, Gujarat, INDIA

E-Mail: mgoyani@gmail.com
Web Site: www.maheshgoyani.in

A.Y: 2015-2016

Last Updated On: 07.08.2015

1
© Mahesh Goyani
 LECTURE NOTES ON
INTRODUCTION TO
DISTRIBUTED OPERATING SYSTEMS

2
© Mahesh Goyani
COURSE DETAIL
TEXT BOOKS

Title Distributed Operating Systems

Author Andrew S. Tanenbaum

Publication Prentice Hall

3
© Mahesh Goyani
COURSE DETAIL
REFERENCE BOOKS

Title Distributed Operating Systems – Concepts & Design

Author Pradeep K. Sinha

Publication PHI

Title Advanced Concepts in Operating Systems

Author Mukesh Singhal, N.G.Shivaratri

Publication Tata McGraw Hill

4
© Mahesh Goyani
COURSE DETAIL
PREREQUISITE

Basics of Operating Systems

C Language
Basic UNIX Commands
Shell Scripting
Socket Programming

5
© Mahesh Goyani
INTRODUCTION

6
© Mahesh Goyani
DISTRIBUTED OPERATING SYSTEM
ROADMAP

Review of OS Concepts
Introduction to Distributed System
Definition & Goal
Hardware Concepts
Software Concepts
Design Issues

7
© Mahesh Goyani
DISTRIBUTED OPERATING SYSTEM
MOTIVATION

Enhancement in microelectronic technology: 8 bit 16 bit 32 bit 64 bit

Availability of Fast, inexpensive, cost effective computers:
Price / performance gain: 1011
Price performance ratio favors use of interconnected, multi processor in place
of single, high speed processor
Invention of high speed computer network: LAN & WAN
64 Kbps to 10/100/1000 MBPS networks
Centralized Approach Distributed Approach

8
© Mahesh Goyani
DISTRIBUTED OPERATING SYSTEM
GOAL

Definition: “A distributed system is a collection of independent computers that

appear to the users of the system as a single computer”
Two aspects:
HARDWARE: Machines are autonomous
SOFTWARE: User think of a system as a single computer
Example: E-Commerce business, Bank with large number of branches
Each user’s workstation + Pool of processors
Single file system
Acts like classical single processor time sharing system

9
© Mahesh Goyani
GOALS
1. ADVANTAGE OF DS OVER CS

Driving force: Economy

Grosch’s Law: Computing power of a CPU is proportional to the square of its
price. (Valid for mainframe computers only ☺ )
Microprocessor technology has better price/performance ratio
10,000 CPU * 50 MIPS = 5,00,000 MPIS
Single processor need to execute instruction in 0.002 ns : Impossible
Einstein's theory of relativity: Light can travel 0.6 mm in 0.002 ns
Distributed system: Allows many users to work together
Parallel system: To achieve maximum speed up on a single problem

10
© Mahesh Goyani
GOALS
1. ADVANTAGE OF DS OVER CS

Some applications are inherently distributed (Bank, Supermarket chain)

Local decisions are made locally
Updates query locally whole the day
Computer Supported Cooperative Work – CSCW: Work together
Computer Supported Cooperative Games – CSCG: Play together ☺
Higher reliability
Dominant consideration in critical applications like nuclear plant
Incremental Growth
Adding or changing mainframe can create havoc

11
© Mahesh Goyani
GOALS
2. ADVANTAGES OF DC OVER INDEPENDENT PCS

Why not independent machine ?

1. Data sharing – Reservation systems
2. Sharing expensive resources like color printer, phototypesetter etc
3. Enhanced person to person communication: Electronic mail
A. Faster than paper mail
B. Does not require both party to be online at same time like telephone
C. Unlike FAX, it is editable
4. Heterogeneous computing environment
A. Let jobs run on the most appropriate machine, rather than owner’s
machine
B. Reliable

12
© Mahesh Goyani
GOALS
3. DISADVANTAGES OF DS

Problems:
1. Software:
A. OS, Programming language, transparency ?
2. Communication network
A. Loss of message
B. Saturated network needs replacement
3. Easy way of data sharing
A. security

Despite of these problems, many people feel that advantages of DS outweigh

the disadvantages

13
© Mahesh Goyani
CLASSIFICATION

14
© Mahesh Goyani
HARDWARE CONCEPT
FLYNN’S CLASSIFICATION

Each DS consists of multiple CPUs, which can be organized in different ways

Flynn’s Classification (1972):
1. SISD: All traditional uniprocessor computers at home and office
2. SIMD: Array processor, Some super computer
3. MISD: No known computer
4. MIMD: All DS

15
© Mahesh Goyani
HARDWARE CONCEPT
CLASSIFICATION BY TANENBAUM

MIMD

Parallel & Distributed

Computers

Tightly Coupled Loosely Coupled

(Less delay, High Data rate) (High delay, Low Data rate)

Multi processors Multi computers

(Shared Memory) (Local Memory)
Parallel system Distributed System

Bus Switched Bus Switched

Sequent, Ultra computer, Workstation on Hypercube,

Encore RP3 LAN Transputer

16
© Mahesh Goyani
HARDWARE CONCEPT
1. BUS BASED MULTIPROCESSOR

CPUs are connected to common bus along with memory

Typical bus has 32 or 64 bit address, data and control line
B reads same as A writes: Coherent
Bus becomes bottleneck with as few as 4-5CPUs
Solution Cache memory (Hit + Miss) Memory becomes incoherent
Write through cache: When word is written to cache, its updated in memory
Snoopy cache: When write occurs in memory, cache entry is either removed
or updated with new value in memory (Always coherent)
Support up to 64 processors
CPU CPU CPU
Memory
Cache Cache Cache

BUS
17
© Mahesh Goyani
HARDWARE CONCEPT
2. SWITCHED MULTIPROCESSOR
M M M M
To build multiprocessor with more than 64
C
processors different method is needed
C
Crossbar switch:
C
Divide memory in modules
C
Connect memory module by cross bar switch
Cross point Switch
CPUs can access memory simultaneously
Cross bar Switch
No two CPUs can access same memory cell at
same time C M

Downside: NM*NC cross point switches C M

Omega switch: Fewer switches

C M
With ‘n’ CPUs and ‘n’ memory units, omega
C M
network requires (nlog2n)/2 switching stage. 2 X 2 Omega Switch
18
Downside: Delay © Mahesh Goyani
HARDWARE CONCEPT
2. SWITCHED MULTIPROCESSOR

Hierarchical approach: Local + Shared memory

NUMA: Non uniform memory access
CPU can access its local memory quickly but accessing anybody else’s
memory is slower
NUMA have better average access times than machines based on omega
networks
Complications: Placement of program and data

19
© Mahesh Goyani
HARDWARE CONCEPT
3. BUS BASED MULTI COMPUTERS

Building multi computer without shared memory is easy

Each CPU has direct access to its own local memory
Problem: How CPUs communicate with each other
CPU to CPU traffic is several orders of magnitude lower than CPU to Memory
Bus need not be high speed backplane bus due to reduced traffic

Workstation Workstation Workstation

Local Local Local
Memory Memory Memory

CPU CPU CPU

Bus

20
© Mahesh Goyani
HARDWARE CONCEPT
4. SWITCHED MULTI COMPUTERS

CPU has direct access to its private memory

Grid: Suitable for problem that have an inherent 2D nature
Path length grows in order of square root of number of CPUs
Hypercube: n dimensional cube ( here n = 4 )
Expand it to five dimension, add set of two interconnected cubes to figure
Message have to make several hops to reach to destination
Path length grows in logarithmic order of number of CPUs
For n-dimensional hypercube, each CPU is connected to n CPUs
16, 384 CPUs are available nowadays

Grid Hypercube
21
© Mahesh Goyani
TYPES OF OPERATING SYSTEM

22
© Mahesh Goyani
SOFTWARE CONCEPT
SOFTWARE CONCEPTS

Image of system presented to user is determined by software

Unlike hardware, OS can not be distinguished cleanly.
Roughly classified as,
Loosely coupled software
Allows users and machines to be independent of each other
Interaction is limited, e.g. communication over LAN
If network goes down, independent machine can still continue to work
Tightly coupled software
Evaluating chess board on multiple processor simultaneously
Software for such system require support from both – application program
and OS

23
© Mahesh Goyani
SOFTWARE CONCEPT
1. NETWORK OPERATING SYSTEM

Loosely coupled software on loosely coupled hardware

Most common combination
E.g. Collection of workstations connected by a LAN
All machine has its own OS
All command runs locally, right on the work station
Sometimes possible to login in to another workstation by remote login
rlogin machine Remote Login
rcp machine1:file1 machine2:file2 Remote file copy

24
© Mahesh Goyani
SOFTWARE CONCEPT
1. NETWORK OPERATING SYSTEM

This form of communication is extremely primitive

One approach is to provide shared file system: File Server
File Server maintain file in hierarchical structure
Client can import or mount and unmount directories
Different client have different view to
File System
Client and server can run different OS,
but should agree on common file format
Very limited coordination

25
© Mahesh Goyani
SOFTWARE CONCEPT
2. TRUE DISTRIBUTED SYSTEM

NOS are loosely coupled software on loosely coupled hardware

Next evolution: Tightly coupled software on same loosely coupled (i.e. multi
computer) hardware: Single machine image / Virtual uniprocessor
User should not have any idea about existence of multiple CPUs in system
Characteristics of DS:
1. There must be single, global IPC mechanism, for local and remote
communication.
2. Process management (create, destroy, start, stop etc) must be same
3. File system must look same every where (e.g. file name length, visibility)
4. Same system call interface identical kernels run on all CPUs
5. Kernel has control to manage own local resources: Swapping, Paging,
Scheduling
26
© Mahesh Goyani
SOFTWARE CONCEPT
3. MULTIPROCESSOR TIMESHARING SYSTEM

Tightly coupled software on tightly coupled hardware

Special purpose machine exists, like database machine
Example: Unix with multiple CPUs: N CPU improve performance N fold
Key characteristic: Single RUN QUEUE in shared memory
Initial execution would be slow due to cache miss.
If possible, allocate the same CPU to the process which comes back after
performing I/O To improve performance E (Ready)

Busy waiting is preferable in case of short I/O D (Ready)

C (Running)
Differs from other systems in organization of file : Lock cache
B (Running)
A (Running)
Process A Process B Process C
Running Running Running Disk Run Queue: D, E
Cache Cache Cache OS
BUS
27
© Mahesh Goyani
SOFTWARE CONCEPT
COMPARISON OF OS

Item NOS DOS MOS

Does it look like a virtual uniprocessor? NO YES YES

Do all have to run same OS? NO YES YES

How many copies of OS are there ? N N 1

How is communication achieved ? Shared files Messages Shared Memory

Are agreed upon network protocols required ? YES YES NO

Is there a single run queue ? NO NO YES

Does file sharing have well defined semantics? Usually NO YES YES

28
© Mahesh Goyani
DESIGN ISSUES

29
© Mahesh Goyani
DESIGN ISSUES
1. TRANSPARENCY

Big Question: How to achieve single system image ?

Transparency can be achieved at two different levels:
1. Hide distribution from user: make command in UNIX to compile the
program Compilation may proceed in parallel on any machines
2. System call interface can be designed in such a way so that existence of
multiple processor is not visible

30
© Mahesh Goyani
DESIGN ISSUES
1. TRANSPARENCY

Type Meaning

Location Users can not tell where software (database, files) and hardware (CPU,
printer) resources are located. Machine1:prog.c is not acceptable

Migration Resources can move at will without changing their names: Directory
hierarchy. /games/news /work/news

Replication User can not tell how many copies exists ( Server forms a ring to
serve/forward user request and replicate heavily used files)

Concurrency Multiple users can share resources automatically (Lock the resource so
multiple user can not access simultaneously)

Parallelism Activities can happen parallel without user knowing (hardest to

achieve). Evaluate chess board on multiple CPU
In case of printer, user don’t wont transparency
31
© Mahesh Goyani
DESIGN ISSUES
2. FLEXIBILITY

We are in learning mode, so there must be a way to correct error or backtrack

Design seem reasonable now may later prove to be wrong later
Monolithic Kernel: Today's’ centralized OS augmented with network facility
and integration of remote services
System calls are made by trapping the kernel, having the work performed
there, and having the kernel return desired result to user process
Machines have their own disk and manage their own local file system: UNIX
Only advantage is performance – Faster than micro kernel (SPRITE)
Directory Process
User User File Server
Server Server

Monolithic Kernel Micro Kernel Micro Kernel Micro Kernel Micro Kernel

Includes file, directory and

process management Network
32
© Mahesh Goyani
DESIGN ISSUES
2. FLEXIBILITY

Micro Kernel: More flexible, provides following services

1. IPC mechanism
2. Some memory management
3. Small amount of low level process management & Scheduling
4. Low level I/O
Unlike monolithic kernel, it does not provide file system, directory structure,
full process management or much system call handling
All other OS services are implemented in user space like read file, write file…
Easy to implement, install and debug services
This method is highly modular with well defined interface
User are free to write their own service
E.g: AMOEBA
33
© Mahesh Goyani
DESIGN ISSUES
3. RELIABILITY

One machine goes down, some other machine serve the purpose
Aspects of Reliability:
1. Availability: Refers to the fraction of time that the system is usable.
Availability can be improved by replicating resources or by enhancing
the design such that critical components are not accessed
simultaneously
Highly reliable system must be highly available.
More copies Better availability Chances of inconsistency
2. Security: Resources must be protected
3. Fault tolerance: Proper arrangement of closely connected servers
Performance degradation

34
© Mahesh Goyani
DESIGN ISSUES
4. PERFORMANCE

No meaning of conquering other design issues if system does not perform well
Running the application on DS should not be worst then running it on single
processor system
Performance matrices:
Response time: Time required to finish a single job
Throughput: Number of jobs per hour
System Utilization: CPU usage
Network capacity consumed: Bandwidth used
To optimize performance in DS, minimize number of messages
Do all task on single machine (Hardly appropriate in DS)
Fine grained : large number of small computation, high interaction Local
Coarse gained : large computation, low interaction, little data Remote
35
© Mahesh Goyani
DESIGN ISSUES
5. SCALABILITY

Network may grow with growth of business

Expand the network by adding machines
Minitel terminal in France Telephone database
Terminals are ready so can be extended to use mail service, other database etc
Guiding principle in DS: AVOID CENTRALIZED COMPONENTS

Concept Example

Centralized component A single mail server for all users

Centralized Table A single online telephone book

Centralized Algorithm Doing routing based on complete information

Potential bottlenecks that should be avoided

36
© Mahesh Goyani
DESIGN ISSUES
5. SCALABILITY

Only decentralized algorithm should be used:

1. No machine has complete information about the system state
2. Machine make decisions based only on local information
3. Failure of one machine does not ruin the algorithm
4. There is no implicit assumption that a global clock exists

37
© Mahesh Goyani
AUTHOR’S PROFILE

Mahesh Goyani has completed his graduation in Computer Engineering from SCET, VNSGU,
Surat in 2005 with distinction. He received his Master Degree in field of Computer
Engineering with 9.38 CPI (81.03 %) from BVM College, SPU, Anand in 2009. He has secured
1st rank twice in university during his master degree. His area of interest is Image Processing,
Computer Algorithms and Computer Graphics. He has also done graduation in Gujarati
literature from Gujarat University in 2014.

Publication: He has published many research papers in national and international journals and conferences. He
was invited as a SESSION CHAIR in International Conference on Engineering, Science and Information Technology,
Tirunelveli, Tamilnadu, Sept - 2011. He has published three books - two on Computer Graphics and one on Design
and Analysis of Algorithms.

Editorial: He is the member of technical review committee of International Journal of Computer Science & Issues
(IJCSE, Mauritius), Electronics & Telecommunication Research Institute (ETRI, Korea), International journal of
Engineering & Technology (IJET, Singapore), International journal of Computer Science & Information Security
(IJCSIS, Pittsburg, USA). He has worked as a program committee member and reviewer in many International
Conferences and Journals. He is also a life time member of ISTE technical society.

Web Site: www.maheshgoyani.in

38
© Mahesh Goyani