CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 14:...

CSCE 668DISTRIBUTED ALGORITHMS AND SYSTEMS

Fall 2011Prof. Jennifer WelchCSCE 668

Set 14: Simulations 1

Motivation

CSCE 668Set 14: Simulations

2

Next section of the course focuses on tools and abstractions for simplifying the design of distributed algorithms.

To approach this rigorously, we need to treat specifications and implementations (a.k.a. "simulations") more generally.

Problem Specifications So Far


3

Approach so far has been problem-specific: put conditions on processor states as

they relate to each other and to initial states

for example: consensus, leader election, etc.

Not so convenient when we want to study simulations from one system model to another, with respect to arbitrary problems

New Way to Specify Problems


4

A problem specification consists of an interface

set of inputs and set of outputs

and a set of allowable sequences of inputs and outputs

This is how users of a solution to the problem communicate with the solution.

A New Way to Specify Problems


5

P inputs outputs

Mutual Exclusion Example


6

inputs: T0, …, Tn-1

Ti indicates pi wants to try to enter the critical section

E0,…, En-1

Ei indicates pi wants to exit the critical section

outputs: C0,…,Cn-1

Ci indicates pi may now enter the critical section

Ri,…,Rn-1 Ri indicates pi may now enter the remainder section

Mutual Exclusion Example


7

MutualExclusion

T1 C1 E1R1

p1

p0p2

T2

C2

E2

R2

T0

C0

E0

R0

Mutual Exclusion Example (cont'd)


8

a sequence of inputs and outputs is allowable iff, for each i, |i cycles through Ti, Ci, Ei, Ri

each proc cycles through trying, critical, exit, and remainder sections in that order

whenever Ci occurs, most recent preceding input or output for any j ≠ i is not Cj only one process is in the critical section at a

time

Mutual Exclusion Example (cont'd)


9

T1 T2 C1 T3 E1 C3 R1 E3 R3

allowable

T1 T2 C1 T3 C3 E1 R1 E3 R3

not allowable

Communication Systems So Far


10

So far, we have explicitly modeled the communication system inbuf and outbuf state components and

deliver events for message passing, explicit shared variables as part of

configurations for shared memory Not so convenient when we want to

study how to provide one kind of communication in software, given another kind.

Different Kinds of Communication Systems


11

Message passing vs. shared memory different interfaces (sends/receives vs.

invocations/responses) Within message passing:

different levels of reliability, ordering different guarantees on content (when

malicious failures are possible) Within shared memory:

different shared variable semantics

What Kinds of Simulations?


12

How to provide broadcast (with different reliability and ordering guarantees) on top of point-to-point message passing

How to provide shared objects on top of message passing

How to provide one kind of shared objects on top of another kind

How to provide stronger synchrony on top of an asynchronous system

How to provide better-behaved faulty processors on top of worse-behaved ones

New Way to Model Communication Systems


13

Interpose a communication system between the processors

A particular type of communication system is specified using the approach just described focus on the desired behavior of the

communication system, as observed at its interface, instead of the details of how that behavior is provided

Asynchronous Point-to-Point Message Passing Example


14

Interface is: inputs: sendi(M)

models pi sending set of msgs M each msg indicates sender and recipient

(must be consistent with assumed topology)

outputs: recvi(M) models pi receiving set of msgs M each msg in M must have pi as its recipient

Asynch MP Example (cont'd)


15

For a sequence of inputs and outputs (sends and receives) to be allowable, there must exist a mapping from the msgs in recv events to msgs in send events s.t. each msg in a recv event is mapped to a msg in a

preceding send event is well-defined: every msg received was

previously sent (no corruption or spurious msgs) is one-to-one: no duplicates is onto: every msg sent is received

Asynchronous Broadcast Example


16

Inputs: bc-sendi(m) an input to the broadcast service pi wants to use the broadcast service to

send m to all the procs Outputs: bc-recvi(m,j)

an output of the broadcast service broadcast service is delivering msg m, sent

by pj, to pi

Asynch Bcast Example (cont'd)


17

A sequence of inputs and outputs (bc-sends and bc-recvs) is allowable iff there exists a mapping from each bc-recvi(m,j) event to an earlier bc-sendj(m) event s.t. is well-defined: every msg bc-recv'ed was

previously bc-sent restricted to bc-recvi events, for each i, is

one-to-one: no msg is bc-recv'ed more than once at any single proc.

restricted to bc-recvi events, for each i, is onto: every msg bc-sent is received at every proc.

Processes


18

A piece of code (process) runs on each processor to simulate the desired communication system.

No longer accurate to identify "the algorithm" with the processor, because there may be several algorithms (processes) running on the same processor. For example: one process (algorithm) that uses the broadcast

service another process (algorithm) that implements the

broadcast service on top of a point-to-point MP system

Modeling Process Stack at a Node


19

layer 1

layer 2

layer 3

environment

communication system

modeled as a problemspec (interface & allowable sequences)

modeled as a problemspec (interface & allowable sequences)

modeledas statemachines

communicate viaappropriate primitives:shared events

Intra-Node Communication Pattern


20

Activity is initiated by a node input (input coming in from environment on top or communication system at bottom)

Triggers some activity at the top (or bottom) layer, which in turn can trigger some activity at the layer above or below

Chain reaction can continue for some time but must eventually die out

All activity at one node, in response to a single node input, is assumed to execute atomically (w.r.t. other nodes)

Definition of Execution


21

Sequence C0 e1 C1 e2 C2 … of alternating configurations and events s.t.

C0 is an initial configuration

event ei is enabled in Ci-1 (there is a transition from the state(s) of the relevant process(es) in Ci-1 labeled ei)

state components of processes change according to the transition functions for ei

can chop the execution into pieces so that each piece starts with a node input all events in each piece occur at the same node the next node input does not occur until no events (other

than node inputs) are enabled

Definition of Admissible Execution


22

We only require an algorithm to be correct if each process is given enough opportunities

to take steps (called fairness) the communication system behaves

"properly" and the environment behaves "properly"

Executions satisfying these conditions are admissible.

Proper Behavior of Communication System


23

The restriction of the execution to the events of the interface at the "bottom of the stack" is an allowable sequence for the problem specification corresponding to the underlying communication system

Example: message passing, every message sent is eventually received

Proper Behavior of Environment


24

The environment (user) interacts "properly" with the top layer of the stack (through the interface events) as long as the top layer is also behaving properly.

Mutex example: the user only requests to leave the critical section if it is currently in the critical section.

Simulations


25

System C1 simulates system C2 if there is a set of processes, one per node, called Sim s.t.

1. top interface of Sim is the interface of C2

2. bottom interface of Sim is the interface of C1

3. For every admissible execution of Sim, the restriction of to the interface of C2 is allowable for C2 (according to its problem spec).

Simulations


26

SimSim0

C2 inputs C2 outputs


C1

Simn-1



…

C2

If user of C2 behaves properly and if C1 behaves properly,then Sim ensures that user of C2 thinks it is really usingC2 (and not C1 plus a simulation layer)

CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 14:...

Documents

Transcript of CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 14:...