Transcript Set 14: Simulations

Set 14: Simulations
CSCE 668
DISTRIBUTED ALGORITHMS AND
SYSTEMS
CSCE 668
Fall 2011
Prof. Jennifer Welch
1
Motivation
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.
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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.

Set 14: Simulations
CSCE 668
A New Way to Specify Problems
5
inputs
P
Set 14: Simulations
outputs
CSCE 668
Mutual Exclusion Example
6

inputs:

T0, …, Tn-1


E0,…, En-1


Ti indicates pi wants to try to enter the critical section
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
Set 14: Simulations
CSCE 668
Mutual Exclusion Example
7
p1
T1
p0
T0
C0
E0
R0
C1 E1R1
T2
Mutual
Exclusion
C2
E2
p2
R2
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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.
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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

Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
Asynch Bcast Example (cont'd)
17

A sequence of inputs and outputs (bc-sends and bcrecvs) 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 bcsent
  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.

Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
Modeling Process Stack at a Node
19
environment
modeled as a problem
spec (interface &
allowable sequences)
layer 1
modeled
as state
machines
communicate via
appropriate primitives:
shared events
layer 2
layer 3
communication system
Set 14: Simulations
modeled as a problem
spec (interface &
allowable sequences)
CSCE 668
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)
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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.
Set 14: Simulations
CSCE 668
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
Set 14: Simulations
CSCE 668
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.
Set 14: Simulations
CSCE 668
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).
Set 14: Simulations
CSCE 668
Simulations
26
C2 inputs
C2 outputs
C2 inputs
…
Sim
Sim0
C1 inputs
C1 outputs
C2
C2 outputs
Simn-1
C1 inputs
C1 outputs
C1
If user of C2 behaves properly and if C1 behaves properly,
then Sim ensures that user of C2 thinks it is really using
C2 (and not C1 plus a simulation layer)
Set 14: Simulations
CSCE 668