Distributed Software Develop - Synchronization - Lecture Slides | CS 682, Study notes of Software Engineering

Download Distributed Software Develop - Synchronization - Lecture Slides | CS 682 and more Study notes Software Engineering in PDF only on Docsity!

Distributed Software Development

Synchronization

Chris Brooks

Department of Computer Science

University of San Francisco

Department of Computer Science — University of San Francisco – p.1/

Time in Distributed Systems

In systems with multiple CPUs, the clocks are unlikely tohave the exact same time.

Variations in manufacturing cause clock skew. Insight: often, it doesn’t matter exactly what time anoperation happens, but what order events occur in. (exception: hard real-time systems)

Department of Computer Science — University of San Francisco – p.2/

Global state

Many interesting problems in distributed computing can beexpressed in terms of determining whether some property p^

is satisfied.^ Consensus^ Deadlock^ Termination^ Load balancing The general version of this problem is called the

Global

Predicate Evaluation Problem

Department of Computer Science — University of San Francisco – p.4/

Synchronization

For example, to detect deadlock, we construct a wait-forgraph.

Edge from process

p

toi

p

j^ if^

pi

is waiting on a message

from

p

.j

If this graph has a cycle, we have deadlock. How do we do this while the computation is running? We can’t pause the computation and collect all theinformation in one place.

Department of Computer Science — University of San Francisco – p.5/

Events and time

Most of the time, we don’t necessarily care about theexact time when each event happens. Instead, we care about the order in which events happenon distributed machines. If we do care about time, then the problem becomes oneof synchronizing about the global value of a clock.

Department of Computer Science — University of San Francisco – p.7/

Distributed Computation

A process

p

consists of a series of eventsi

e

1 , e i^

2 , ... i^

There are three types of events:

Local events - no communication with other processes Send events Receive events a^

local history

is a sequence of events

e

1 , e i^

2 , ... i^

such that

order is preserved.

Department of Computer Science — University of San Francisco – p.8/

Cause and Effect

Cause and effect can be used to produce a partialordering. Local events are ordered by identifier. Send and receive events are ordered.

If^

p^1

sends a message

m

1 to

p

send

(m

must occur

before

receive

(m

Assume that messages are uniquely identified. If two events do not influence each other, even indirectly,we won’t worry about their order.

Department of Computer Science — University of San Francisco – p.10/

Happens before

The

happens before

relation is denoted

Happens before is defined:

If^

kei , e

landi^

k < l

, then

e

k i^

e

l i

(sequentially ordered events in the same process) If^

ei

send

(m

)^

and

e

j^

receive

(m

), then

e

→i

e

j

(send must come before receive) If^

e^

e

′^ and

e

′^ →

e

′′, then

e

e

′′

(transitivity) If^

e^

e

′^ and

e

′^6 →

e

, then we say that

e

and

e

′^ are

concurrent. (

e||

′e

These events are unrelated, and could occur in eitherorder.

Department of Computer Science — University of San Francisco – p.11/

• p^1 p^2 p Space-time diagram
• 1 e
• 2 e
• 3 e
• 4 e - 1 e - 2 e - 3 e - 4 e - 1 e - 2 e - 3 e - 4 e

Space-time diagram

Arrows indicate messages sent between processes. Causal relation between events is easy to detect Is there a directed path between events?^1 e^1

e

4 3

(^2) e 1 ||e

1 3

Department of Computer Science — University of San Francisco – p.14/

Cuts

The

frontier

of the cut is the last state in each process.

We’ll use a cut to try to specify the global state of acomputation at some point in time ... A

run

is a total ordering over events that is consistent with

each local history.

A distributed computation can have many runs.

Department of Computer Science — University of San Francisco – p.16/

Monitoring a distributed

computation

So how can we use all of this to solve the GPE problem? We want to know what the global state of the system is atsome point in time ... Solution 1: Create

p

, the 0

monitor

process.

The monitor sends each process an ’inquiry’ message. Each process responds by sending its current local state σi Once all local states are received, these define the frontierof a cut. This cut is the global state. Will this work?

Department of Computer Science — University of San Francisco – p.17/

Monitoring a distributed

computation

p^1 p^2 p^3

(^1) e 1

(^2) e 1

(^3) e 1

(^4) e 1

(^1) e 2

(^2) e 2

(^3) e 2

(^1) e 3

(^2) e 3

(^3) e 3

(^4) e 3 (^5) e 1

Cut

req req

reply

req

reply

req

Department of Computer Science — University of San Francisco – p.19/

Monitoring a distributed

computation

Suppose

p

1 receives the monitor message after

e

p

2

after

(^2) e 2 , and

p

3 after

e

The WFG has edges (1,3), (2,1), (3,2). The system is not really deadlocked, though; the monitorreceived an inconsistent picture. This is called a ghost deadlock. Problem: process

p

’s state reflects receiving a message 3

that (according to the monitor)

p

1

never sent.

Active monitoring isn’t going to work.

Department of Computer Science — University of San Francisco – p.20/