7/29/2019 RMCS.ppt

1/127

Resource Management ofComputer Systems

Ms. Amita Rathee Dahiya

A.P.(IT)

P.D.M.C.E.

7/29/2019 RMCS.ppt

2/127

What is an Operating System? an intermediary between the user of a

computer and the computer hardware

manages the computer hardware

an amazing aspect of operating systems ishow varied they are in accomplishing thesetasks mainframe operating systems

personal computer operating systems

operating systems for handheld computers

7/29/2019 RMCS.ppt

3/127

What is an Operating System?

An operating system (OS) is:

a software layer to abstract away and manage

details of hardware resources a set of utilities to simplify application development

Applications

OS

Hardware

7/29/2019 RMCS.ppt

4/127

What is a distributed system?

&

What are the design goals?

7/29/2019 RMCS.ppt

5/127

Distributed System

7/29/2019 RMCS.ppt

6/127

Goals of Distributed System

7/29/2019 RMCS.ppt

7/127

What is distribution transparency?

7/29/2019 RMCS.ppt

8/127

Distribution Transparency

Depending on which computing system you use, you will have

to consider the byte order in which multibyte numbers are

stored, particularly when you are writing those numbers to a

file. The two orders are called "Little Endian" and "Big Endian".

Goal of Transparency

Hide all irrelevant system-dependent details from the user andsystem programmer and create the illusion of a simple and

easy to use system

7/29/2019 RMCS.ppt

9/127

Transparency in a Distributed

System

7/29/2019 RMCS.ppt

10/127

Openness in DistributedSystems An open distributed system

Offers services according to standard rules that describesyntax and semantics of the services

Can interact with services from other open systems,irrespective of the underlying environment

Examples

In computer networks, standard rules govern the format,contents and meaning of messages sent and received

In distributed systems, services are specified throughinterface description language (IDL)

7/29/2019 RMCS.ppt

11/127

Scale in Distributed System

7/29/2019 RMCS.ppt

12/127

Centralized Solutions: Obstaclesfor Achieving Size Scalability

Examples of scalability limitations.

Concept Example

Centralized services A single server for all users

Centralized data A single on-line telephone book

Centralized

algorithms

Doing routing based on complete

information

7/29/2019 RMCS.ppt

13/127

Characteristics ofDecentralized Algorithms No machine has complete information about the system

state

Machines make decisions based only on local information

Failure of one machine does not ruin the algorithm

Three is no implicit assumption that a global clock exists

7/29/2019 RMCS.ppt

14/127

Techniques for Scalability

7/29/2019 RMCS.ppt

15/127

7/29/2019 RMCS.ppt

16/127

ScalingThe Problem

7/29/2019 RMCS.ppt

17/127

Internet/World Wide Web

Types of Distributed Systems

7/29/2019 RMCS.ppt

18/127

Distributed Computing

System

7/29/2019 RMCS.ppt

19/127

7/29/2019 RMCS.ppt

20/127

7/29/2019 RMCS.ppt

21/127

Cloud Computing

A cloud is an elastic execution

environment of resources

providing a metered service at

multiple granularities.

On-demand resource

allocation: add and subtract

processors, memory, storage.

7/29/2019 RMCS.ppt

22/127

Amazon Web Services

Elastic Compute Cloud (EC2)

Rent computing resources by the hour Basic unit of accounting = instance-hour

Additional costs for bandwidth Simple Storage Service (S3)

Persistent storage Charge by the GB/month

Additional costs for bandwidth Youll be using EC2 for a programming assignment!

7/29/2019 RMCS.ppt

23/127

Distributed InformationSystem

7/29/2019 RMCS.ppt

24/127

Transaction

7/29/2019 RMCS.ppt

25/127

Transaction Processing

Monitor

7/29/2019 RMCS.ppt

26/127

Distributed Pervasive

Systems

7/29/2019 RMCS.ppt

27/127

Sensor Networks

7/29/2019 RMCS.ppt

28/127

Sensor Networks as

Distributed System

7/29/2019 RMCS.ppt

29/127

1.4 Internet

intranetISP

desktop computer:

backbone

satellite linkserver:

%

network link:

%

%%

29

7/29/2019 RMCS.ppt

30/127

1.4.1 World-Wide-Web

30

7/29/2019 RMCS.ppt

31/127

1.4.2 Web Servers and Web

Browsers

Internet

BrowsersWeb servers

www.google.com

www.uu.se

www.w3c.org

ProtocolsActivity.html

http://www.w3c.org/Protocols/Activity.html

http://www.google.comlsearch?q=lyu

http://www.uu.se/

File system ofwww.w3c.org

31

Instructors Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design Edn. 5 Pearson Education 2012

7/29/2019 RMCS.ppt

32/127

Announcement

To build our class roster

Send our TA Weiyue Xu (weiyue AT

cse.unl.edu) an email with subjectCSCE455/855 roster, your photo (

7/29/2019 RMCS.ppt

33/127

Distributed Systems

Design Issues

7/29/2019 RMCS.ppt

34/127

Definition:

Distributed operating system:

Integration of system services presenting a

transparent view of a multiple computer system

with distributed resources and control.

Consisting of concurrent processes accessing

distributed shared or replicated resources

through message passing in a networkenvironment.

7/29/2019 RMCS.ppt

35/127

Problems Unique to Distributed

Systems

Distributed Operating Systems: Generation: Third Generation Operating System. Characteristics: Global view of file system, name

space, time, security, computational power. Goal: Single computer view of multiple computer

system (transparency)

Distributed Operating System Goals:

Efficiency Consistency Robustness

7/29/2019 RMCS.ppt

36/127

Efficiency

Efficiency problem: Communication

delays

Data propagation Overhead of communication protocols Load distribution

7/29/2019 RMCS.ppt

37/127

Consistency

Consistency Problem:

Users perspective: Uniformity in using the system

Predictability of the systems behavior Systems perspective:

Integrity maintenance Concurrency control

Failure handling Recovery procedures

7/29/2019 RMCS.ppt

38/127

Robustness

Robustness Problems:

Fault tolerance

What to do when a message is lost? Handling of exceptional situations and errors Changes in the system topology Long message delays

Inability to locate a server Security for the users and the system

7/29/2019 RMCS.ppt

39/127

Implementation Issues

Objects models and identification.

Distributed Coordination.

Interprocess Communication Distributed Resources.

Fault Tolerance and Security.

7/29/2019 RMCS.ppt

40/127

Identification / Name

Design Issue Example: Resource identification [2]

The resources in a distributed system are spread acrossdifferent computers and a naming scheme has to bedevised so that users can discover and refer to the

resources that they need.

An example of such a naming scheme is the URL(Uniform Resource Locator) that is used to identify WWWpages. If a meaningful and universally understoodidentification scheme is not used then many of theseresources will be inaccessible to system users.

7/29/2019 RMCS.ppt

41/127

Object Model and Naming

Schemes [1]

Objects: processes, files, memory, devices, processors, and

networks.

Object access:

Each object associate with a defined access operation. Accesses via object servers Identification of a server by:

Name Physical or Logical address

Service that the servers provide. Identification Issue: Multiple server addresses may exist requiring a server to

move requiring the name to be changed.

7/29/2019 RMCS.ppt

42/127

Distributed Coordination [1]

Processes Coordination required to

achieve synchronization:

Synchronization Types: Barrier synchronization: Condition Coordination:

Mutual exclusion:

7/29/2019 RMCS.ppt

43/127

Synchronization Types

Barrier Synchronization:

Process must reach a common synchronization pointbefore they can continue:

Condition Coordination: A process must wait for a condition that will be set

asynchronously by other interacting processes to

maintain some ordering of execution.

Mutual Exclusion: Concurrent processes must have mutual exclusion

when accessing a critical shared resource.

7/29/2019 RMCS.ppt

44/127

Synchronization Issues:

State information sent by messages: Typically only partial state information is known about

other processes making synchronization difficult.

Information not current due to transfer time delay. Decision if process may continue must rely on

a message resolution protocol. Centralized Coordinator:

Central point of failure

Deadlocks Circular Waiting for the other process Deadlock detection and recovery strategies.

7/29/2019 RMCS.ppt

45/127

Interprocess Communication [1]

Lower level: message passing

Higher level logical communication providestransparency

Client/server model communication.All system communication are seen as a pair of

message exchanges between the client and server.

Remote Procedure Call, (RPC), communication.

RPC built on top of client/server model. Request/reply message passing as used inprogramming procedure-call concept.

7/29/2019 RMCS.ppt

46/127

Interprocess Communication

Issues

Susceptible to failures in the system due

to having to communicate through

several protocol layers.

7/29/2019 RMCS.ppt

47/127

Distributed Resources [1]

Resources: Data (Storage) Processing capacity (Sum of all processors)

Transparency of Data distribution:

Distributed file systems Single file system view in distributed environment. Distributed shared memory

Single shared memory view of physically distributed memories. Issue: Sharing and replication of data/Memory.

Transparency of process allocating:

Applications are constrained by time, thus scheduling ofprocess must satisfy a real-time requirement. Load Distribution Schemes

7/29/2019 RMCS.ppt

48/127

Load Distribution Schemes

Static Load Distribution: Multiprocessor scheduling Objective: Minimize the completion time of processes

Issue: Minimize communication overhead withefficient scheduling. Dynamic Load Distribution:

Load sharing

Objective: Maximize the utilization of processors. Issue: Process migration strategy & mechanism.

7/29/2019 RMCS.ppt

49/127

Fault Tolerance and Security [1]

Failures & Security Threats:

Openness inherent in Distributed Environments System Failures:

Failures: Faults due to unintentional intrusions Security Violations: Faults due to intentional intrusions.

Issue: Fault Tolerance

Faults Transparent to user: System Redundancy (Inherent property in Distributed Systems) Systems Ability to Recovery. (Rolling back failed processes)

Security Issue: Authentication & Authorization Access control over across network with different

administrative units & varying security models.

7/29/2019 RMCS.ppt

50/127

Summary of Issues [3]

Issue

Communication, Synchronization,distributed algorithms

Process scheduling, deadlockhandling, load balancing

Resource scheduling, file sharing,concurrency control

Failure handling, configuration,redundancy

Affect Service

Interaction and Control

Performance

Resource

System Failures

7/29/2019 RMCS.ppt

51/127

Issues Governing Quality of Service

The quality of service offered by asystem reflects its performance,availability and reliability. It is affectedby a number of factors such as theallocation of processes to processes inthe system, the distribution of

resources across the system, thenetwork and the system hardware andthe adaptability of the system.

7/29/2019 RMCS.ppt

52/127

References

[1] Randy Chow & Theodore Johnson,1997,Distributed Operating Systems &Algorithms, (Addison-Wesley), p. 45 to 50.

[2] Ian Sommerville, 2000, Software Engineering, 6thedition, Chapter 11.

[3] Pierre Boulet, 2006, Distributed Systems:Fundemental Concepts

7/29/2019 RMCS.ppt

53/127

Distributed Systems

Except as otherwise noted, the content of this presentation is licensed under the Creative Commons Attribution

2.5 License.

Logical Clocks

7/29/2019 RMCS.ppt

54/127

Logical clocks

Assign sequence numbers to messages

All cooperating processes can agree on orderof events

vs. physical clocks: time of day

Assume no central time source

Each system maintains its own local clock No total ordering of events

No concept ofhappened-when

7/29/2019 RMCS.ppt

55/127

Happened-before

Lamports happened-before notation

a

b event a happened before event be.g.: a: message being sent, b: message

receipt

Transitive:

ifab and b c then a c

7/29/2019 RMCS.ppt

56/127

Logical clocks & concurrency

Assign clock value to each event

if ab then clock(a) < clock(b)

since time cannot run backwards

Ifa and b occur on different processes that

do not exchange messages, then neithera

b norb a are true

These events are concurrent

7/29/2019 RMCS.ppt

57/127

Event counting example

Three systems: P0, P1, P2

Events a, b, c,

Local event counter on each system

Systems occasionally communicate

7/29/2019 RMCS.ppt

58/127

Event counting examplea b

h i

k

P1

P2

P3

1 2

1 3

21

d fg

3 c

2

4 6e5

j

7/29/2019 RMCS.ppt

59/127

Event counting examplea b

i

kj

P1

P2

P3

1 2

1 3

21

d fg

3 c

2

4 6

Bad ordering:

e h

fk

he5

7/29/2019 RMCS.ppt

60/127

Lamports algorithm

Each message carries a timestamp of

the senders clock

When a message arrives:

if receivers clock < message timestampset system clock to (message timestamp +

1)

else do nothing

Clock must be advanced between an

7/29/2019 RMCS.ppt

61/127

Lamports algorithm

Algorithm allows us to maintain time

ordering among related events

Partial ordering

7/29/2019 RMCS.ppt

62/127

Event counting example

a bi

kj

P1

P2

P3

1 2

1 7

21

d fg

3 c

2

4 6

6

7

he5

7/29/2019 RMCS.ppt

63/127

Summary

Algorithm needs monotonicallyincreasing software counter

Incremented at least when events thatneed to be timestamped occur

Each event has a Lamport timestampattached to it

For any two events, where a b:

7/29/2019 RMCS.ppt

64/127

Problem: Identical timestamps

ab, bc, : local events sequenced

ic, fd , dg, : Lamport imposes a

sendreceive relationship

Concurrent events (e.g., a & i) may have thesame timestamp or not

a bh i

kj

P1

P2

P3

1 2

1 7

71

d fg

3 c

6

4 6

e5

7/29/2019 RMCS.ppt

65/127

Unique timestamps (total

ordering)We can force each timestamp to be unique

Define global logical timestamp (Ti, i) Ti represents local Lamport timestamp i represents process number (globally unique)

E.g. (host address, process ID)

Compare timestamps:(Ti, i) < (Tj, j)

if and only if

Ti

< Tj

or

Ti = Tj and i < j

Does not relate to event ordering

Unique (totally ordered) timestamps

7/29/2019 RMCS.ppt

66/127

Unique (totally ordered) timestamps

a bi

kj

P1

P2

P3

1.1 2.1

1.2 7.2

7.31.3

d fg

3.1c

6.2

4.1 6.1

h

e5.1

7/29/2019 RMCS.ppt

67/127

Problem: Detecting causal relations

If L(e) < L(e) Cannot conclude that ee

Looking at Lamport timestamps Cannot conclude which events are causallyrelated

Solution: use a vector clock

7/29/2019 RMCS.ppt

68/127

Vector clocksRules:

1.Vector initialized to 0 at each processVi[j] = 0 fori, j=1, , N

2.Process increments its element of the vectorin local vector before timestamping event:

Vi[i] = V

i[i] +1

3.Message is sent from process Piwith Viattached to it

4.When Pjreceives message, comparesvectors element by element and sets localvector to higher of two values

Vj[i] = max(Vi[i], Vj[i]) for i=1, , N

7/29/2019 RMCS.ppt

69/127

Comparing vector timestamps

DefineV = V iff V[i] = V[i] fori= 1 N

V V iff V[i] V[i] fori= 1 N

For any two events e, e

if e e then V(e) < V(e)

Just like Lamports algorithm

ifV(e) < V(e) then ee

Two events are concurrent ifneither

V(e)

V(e) nor V(e)

V(e)

7/29/2019 RMCS.ppt

70/127

Vector timestamps

a bc d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

7/29/2019 RMCS.ppt

71/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

7/29/2019 RMCS.ppt

72/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

(2,0,0)

7/29/2019 RMCS.ppt

73/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

(2,0,0)

(2,1,0)

7/29/2019 RMCS.ppt

74/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

(2,0,0)

(2,1,0) (2,2,0)

7/29/2019 RMCS.ppt

75/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

e 0 0 1

(2,0,0)

(2,1,0) (2,2,0)

(0,0,1)

7/29/2019 RMCS.ppt

76/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

e 0 0 1

(2,0,0)

(2,1,0) (2,2,0)

(0,0,1) (2,2,2)

7/29/2019 RMCS.ppt

77/127

(0,0,1)

(1,0,0)Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

e 0 0 1

(2,0,0)

(2,1,0) (2,2,0)

(2,2,2)

concurrent

events

7/29/2019 RMCS.ppt

78/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

e 0 0 1

(2,0,0)

(2,1,0) (2,2,0)

(0,0,1) (2,2,2)

concurrent

events

7/29/2019 RMCS.ppt

79/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

e 0 0 1

(2,0,0)

(2,1,0) (2,2,0)

(0,0,1) (2,2,2)

concurrentevents

7/29/2019 RMCS.ppt

80/127

Vector timestampsa b

c d

fe

(0,0,0)P1

P2

P3

(0,0,0)

(0,0,0)

(1,0,0)

Event timestamp

a (1,0,0)

b (2,0,0)

c (2,1,0)

d (2,2,0)

e 0 0 1

(2,0,0)

(2,1,0) (2,2,0)

(0,0,1) (2,2,2)

concurrentevents

7/29/2019 RMCS.ppt

81/127

Summary: Logical Clocks &

Partial Ordering

Causality

Ifa->b then event a can affect event b

Concurrency If neithera->b norb->a then one event cannotaffect the other

Partial Ordering

Causal events are sequenced Total Ordering

All events are sequenced

7/29/2019 RMCS.ppt

82/127

The end.

7/29/2019 RMCS.ppt

83/127

Models and Clocks

Ch t i ti f Di t ib t d

7/29/2019 RMCS.ppt

84/127

Characteristics of a Distributed

System

Absence of a shared clockAbsence of shared memory

Absence of failure detection

7/29/2019 RMCS.ppt

85/127

Model of a Distributed System

Asynchronous

Message Passing

7/29/2019 RMCS.ppt

86/127

A Simple Distributed Program

Each process is defined as a set of

states

M d l f Di t ib t d

7/29/2019 RMCS.ppt

87/127

Model of a Distributed

Computation

Interleaving model

A global sequence of events eg.

P1 sends what is my checking balance to P2 P1 sends what is my savings balance to P2 P2 receives what is my checking balance from P1 P1 sets total to 0 P2 receives what is my savings balance from P1 P2 sends checking balance = 40 to P1 P1 receives checking balance = 40 from P2 . . .

M d l f Di t ib t d

7/29/2019 RMCS.ppt

88/127

Model of a Distributed

Computation

Happened before model

Happened before relation Ife occurred before fin the same process, thene --> f

Ife is the send event of a message and fis thereceive event of the same message, then e --> f

If there exists an event gsuch that e --> gand g -->f, then e --> f

A i th h d b f

7/29/2019 RMCS.ppt

89/127

A run in the happened-before

model

7/29/2019 RMCS.ppt

90/127

Logical Clocks

A logical clock C is a map from the set of

events E to N (the set of natural

numbers) with the following constraint:

7/29/2019 RMCS.ppt

91/127

Lamport's logical clock algorithm

publicclass LamportClock {

int c;

public LamportClock() {

c =1;

}

publicint

getValue() {

return c;

}

publicvoid tick() { // on internal actions

c = c + 1;

}

publicvoid sendAction() {// include c in message

c = c + 1;

}

publicvoid receiveAction(int src, int sentValue) {

c = Util.max(c, sentValue) + 1;

}

7/29/2019 RMCS.ppt

92/127

Vector Clocks

Map from the set of states to vectors of

natural numbers with the constraint:

For all s, t: s--> t iff s.v < t.v ...... where s.visthe vector assigned to the state s.

Given vectorsx,y : x < y

All elements ofxare less than or equal to thecorresponding elements ofy

At least one element ofxis strictly less thanthe corresponding element ofy

A Vector clock algorithm

7/29/2019 RMCS.ppt

93/127

A Vector clock algorithm

publicclass VectorClock {

publicint[] v;int myId;

int N;

public VectorClock(int numProc, int id) {

myId = id;

N = numProc;

v =newint[numProc];for (int i =0; i < N; i++) v[i] =0;

v[myId] =1;

}

publicvoid tick() {

v[myId]++;

}publicvoid sendAction() {

//include the vector in the message

v[myId]++;

}

publicvoid receiveAction(int[] sentValue) {

for (int i =0; i < N; i++)

A ti f th t l k

7/29/2019 RMCS.ppt

94/127

An execution of the vector clock

algorithm

7/29/2019 RMCS.ppt

95/127

Direct-Dependency Clocks

Weaker version of the vector clock

Maintain a vector clock locally

Process sends only its local component of the

clock Directly precedes relation: only one message

in the happened-before diagram of thecomputation

Direct-dependency clocks satisfy

A Di t d d l k l ith

7/29/2019 RMCS.ppt

96/127

A Direct-dependency clock algorithmpublicclass DirectClock {

publicint[] clock;

int myId;public DirectClock(int numProc, int id) {

myId = id;

clock =newint[numProc];

for (int i =0; i < numProc; i++) clock[i] =0;

clock[myId] =1;

}publicint getValue(int i) {

return clock[i];

}

publicvoid tick() {

clock[myId]++;

}publicvoid sendAction() {

// sentValue = clock[myId];

tick();

}

publicvoid receiveAction(int sender, int sentValue) {

clock[sender] = Util.max(clock[sender], sentValue);

7/29/2019 RMCS.ppt

97/127

Matrix Clocks

N x N matrix

Gives processes additional knowledge

The matrix clock algorithm

7/29/2019 RMCS.ppt

98/127

publicclass MatrixClock {

int[][] M; int myId; int N;

public MatrixClock(int numProc, int id) {

myId = id; N = numProc;

M =newint[N][N];

for (int i =0; i < N; i++)

for (int j =0; j < N; j++)

M[i][j] =0;

M[myId][myId] =1;

}

publicvoid tick() {

M[myId][myId]++;

}

publicvoid sendAction() {

//include the matrix in the message

M[myId][myId]++;

}

publicvoid receiveAction(int[][] W, int srcId) {

// component-wise maximum of matrices

for (int i =0; i < N; i++)

if (i != myId) {

for (int =0; < N; ++)

7/29/2019 RMCS.ppt

99/127

Lecture 9

SE-9048

Concurrency & Distributed System

Huma Ayub (huma.ayub@uettaxila.edu.pk)

Assistant ProfessorSoftware Engineering Department

99

SYNCHRONIZATION TIME, EVENT,

CLOCKS

PART 4

7/29/2019 RMCS.ppt

100/127

Vector Clocks

100

7/29/2019 RMCS.ppt

101/127

Vector Clocks

Vector Clocks was proposed to overcome the limitation ofLamportsclock: the fact that C(a)

7/29/2019 RMCS.ppt

102/127

Example

Our timestamp is now a vector of numbers,

with each element corresponding to a

process. Each process knows its position in

the vector. For example, the vectorcorresponds to the processes (P0, P1, P2) are

given as :

If a process P0

has four events, a, b, c, d,

they would get Vector timestamps of(1,0,0),

(2, 0, 0), (3, 0, 0), (4, 0, 0). If a process P2

has four events, a, b, c, d, they would get

Vector timestamps of 0,1,0), (0, 2, 0), (0, 3,102

U d ti V t Cl k

7/29/2019 RMCS.ppt

103/127

Updating Vector Clocks

Vector clocks are constructed by the

following two properties:

1.VCi[i]is the number of events that haveoccurred at process Piso farVCi[i]is the local logical clock at process Pi

2.IfVCi[j]=k, then Pi knows that k events haveoccurred at PjVCi[j]is Pis knowledge of local time at Pj

IncrementVCi whenever a

new event occurs

Pass VCj along with the

message 103

7/29/2019 RMCS.ppt

104/127

Updating Vector Clocks

The entire vector is sent along with a message.When the message is received by a process(that is an event that will get a timestamp), thereceiving process does the following:

increment the counter for the process' position inthe vector, just as it would prior to timestampingany local event.

Perform an element-by-element comparison ofthe received vector with the process' timestampvector. Set the process' timestamp vector to thehigher of the values:

104

7/29/2019 RMCS.ppt

105/127

Whenever there is a new event at Pi, incrementVCi[i] When a process Pi sends a messagemto Pj:

IncrementVCi[i] Setms timestamp ts(m) to the vectorVCi

When message m is received process Pj :VCj[k] = max(VCj[k], ts(m)[k]) ; (for all k)

IncrementVCj[j]

Vector Clock Update Algorithm

P0

P1

P2

VC0=(1,0,0) VC0=(2,0,0)VC0=(0,0,0)

VC1=(0,0,0)

VC2=(0,0,0)

m:(2,0,0)VC1=(2,1,0)

105

Inferring Events with Vector

7/29/2019 RMCS.ppt

106/127

Inferring Events with Vector

Clocks Let a process Pi send a messagemto Pj with timestampts(m), then:

Pjknows the number of events at the senderPi that causally

precedem

(ts(m)[i] 1)denotes the number of events at Pi Pjalso knows the minimum number of events at other

processes Pk that causally precedem

(ts(m)[k] 1)denotes the minimum number of events at Pk

P0

P1

P2

VC0=(1,0,0) VC0=(2,0,0)VC0=(0,0,0)

VC1=(0,0,0)

VC2=(0,0,0)

m:(2,0,0)

VC1=(2,2,0)

VC2=(2,3,1)m:(2,3,0)

VC1=(2,3,0)VC1=(0,1,0)

106

7/29/2019 RMCS.ppt

107/127

VECTOR CLOCK

To determine if two events are concurrent, do anelement-by-element comparison of thecorresponding timestamps.

If each element of timestamp V is less than or equal

to the corresponding element of timestamp W then Vcausally precedes W and the events are notconcurrent.

If each element of timestamp V is greater than or

equal to the corresponding element of timestamp Wthen W causally precedes V and the events are notconcurrent.

If, on the other hand, neither of those conditionsapply and some elements in V are greater than while

others are less than the corresponding element in W107

7/29/2019 RMCS.ppt

108/127

108

The timestamp for m is less than the timestampfor g because each element in m is less than or

equal to the corresponding element in g. That is,

0 6 0 1 and 2 2

7/29/2019 RMCS.ppt

109/127

SummaryLogical Clocks

Logical Clocks are employed when processes have

to agree on relative ordering of events, but not

necessarily actual time of events

Two types of Logical Clocks

Lamports Logical Clocks Supports relative ordering of events across different processes by

using happen-before relationship

Vector Clocks Supports causal ordering of events

109

7/29/2019 RMCS.ppt

110/127

Distributed Mutual Exclusion

Synchronization in Distributed SystemsSynchronization in distributed systems are often more difficult

compared to synchronization in uniprocessor and multiprocessor

systems.

Synchronization in Distributed

7/29/2019 RMCS.ppt

111/127

Synchronization in Distributed

Systems

Synchronization in time achieved by ClockSynchronization algorithms

Synchronization between resources - MutualExclusion algorithms

Synchronization in activities - DistributedTransaction paradigms

7/29/2019 RMCS.ppt

112/127

Distributed Mutual Exclusion

Mutual Exclusion

Mutual exclusion (often abbreviated to mutex) algorithms are

used in concurrent programming to avoid the simultaneous use

of a common resource, such as a global variable, by pieces

of computer code called critical sections.

7/29/2019 RMCS.ppt

113/127

Distributed Mutual Exclusion

Critical Sections

In concurrent programming a critical section is a piece of code

that accesses a shared resource (data structure or device) that

must not be concurrently accessed by more than one thread of

execution. A critical section will usually terminate in fixed time,

and a thread, task or process will only have to wait a fixed time

to enter it. Some synchronization mechanism is required at the

entry and exit of the critical section to ensure exclusive use, for

example a semaphore.

7/29/2019 RMCS.ppt

114/127

Distributed Mutual Exclusion

Achieving Mutual exclusion

Hardware solutions - Disabling interrupts on entryinto the critical section

System variables - By using semaphoresimplemented as Locks

Software solutions - Mutual Exclusion Algorithms

I. Distributed Mutual

Exclusion [1]

7/29/2019 RMCS.ppt

115/127

Exclusion [1]

Mutual exclusion ensures that

concurrent processes make a serialized

access to shared resources or data.

A distributed mutual exclusion algorithm

achieves mutual exclusion using only

peer communication. The problem can

be solved using either a contention-based or a token-based approach.

Mutual Exclusion Algorithms

7/29/2019 RMCS.ppt

116/127

Mutual Exclusion

algorithms

Centralized

algorithms

Distributed

Algorithms

Contention Based

Algorithms

Controlled

Algorithms

(Token based algorithms)

Tree Structure

Broadcast Structure

Ring Structure

Timestamp prioritized schemes

Voting schemes

Mutual ExclusioncentralizedAlgorithm

7/29/2019 RMCS.ppt

117/127

a)

Process 1 asks the coordinator for permission to enter a criticalregion. Permission is granted

b) Process 2 then asks permission to enter the same criticalregion. The coordinator does not reply.

c) When process 1 exits the critical region, it tells the coordinator,when then replies to 2

7/29/2019 RMCS.ppt

118/127

Centralized algorithms contd..

AdvantagesFair algorithm, grants in the order of requestsThe scheme is easy to implementScheme can be used for general resource allocation

Critical Question: When there is no reply, does thismean that the coordinator is dead or just busy?

Shortcomings

Single point of failure. No fault toleranceConfusion between No-reply and permission deniedPerformance bottleneck of single coordinator in a

large system

7/29/2019 RMCS.ppt

119/127

Distributed Algorithms

Contention-based Mutual Exclusion Timestamp Prioritized Schemes Voting Schemes

Token-based Mutual Exclusion Ring Structure Tree Structure Broadcast Structure

Contention-based Mutual

7/29/2019 RMCS.ppt

120/127

Exclusion[1]

A contention-based approach meansthat each process freely and equallycompetes for the right to use shared

resource by using a request controlcriteria.

The fairest way is to grant the request tothe process which asked first(Timestamp Prioritized scheme) or theprocess which got the most votes fromthe other processes (Voting scheme).

7/29/2019 RMCS.ppt

121/127

Ricart & Agrawalas Distributedmutual exclusion Ricart & Agrawala came up with a

distributed mutual exclusion algorithm in

1981. It requires the following:

total ordering of all events in a system

(e.g. Lamport's algorithm or others).

messages are reliable (every message is

acknowledged).

7/29/2019 RMCS.ppt

122/127

Ricart & Agrawalas Distributedmutual exclusion When a process wants to enter a critical section,

it:

1. composes a message containing {mesage

identifier(machine, proc#), name of critical section, timestamp).

2. sends a requestmessage to all otherprocesses in the group (may use reliable group

communication). 3. wait until everyone in the group has given

permission.

4. enter the critical section.

7/29/2019 RMCS.ppt

123/127

Ricart & Agrawalas Distributedmutual exclusion When a process receives a request

message, it may be in one of three

states:

Case 1: The receiver is not interested in

the critical section, send reply (OK) to

sender.

Case 2: The receiver is in the critical

section; do not reply and add the request

to a local queue of requests.

7/29/2019 RMCS.ppt

124/127

Ricart & Agrawalas Distributedmutual exclusion Case 3: The receiver also wants to enter

the critical section and has sent its request.

In this case, the receiver compares the

timestamp in the

received message with the one that it has

sent out. The earliest timestamp wins. If the

receiver is the loser, it sends a reply (OK) tosender. If the receiver has the earlier

timestamp, then it is the winner and does not

reply. Instead, it adds the request to its

ueue

7/29/2019 RMCS.ppt

125/127

Ricart & Agrawalas Distributedmutual exclusion When the process is done with its critical

section, it sends a reply (OK) to

everyone on its queue and deletes the

processes from the queue

7/29/2019 RMCS.ppt

126/127

7/29/2019 RMCS.ppt

127/127

Pros and Cons

One problem with this algorithm is that a singlepoint of failure has now been replaced with npoints of failure.

A poor algorithm has been replaced with one

that is essentially n times worse. All is not lost. We can patch this omission up by

having the sender always send a reply to amessage... either an OKor a NO. When therequest or the reply is lost, the sender will time

out and retry. Still, it is not a great algorithm andinvolves quite a bit of message traffic but itdemonstrates that a distributed algorithm is at