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

2. 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.

3. Problem Specifications So Far CSCE 668Set 14: Simulations 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

4. New Way to Specify Problems CSCE 668Set 14: Simulations 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.

5. A New Way to Specify Problems CSCE 668Set 14: Simulations 5 P inputs outputs

6. Mutual Exclusion Example CSCE 668Set 14: Simulations 6  inputs:  T 0, …, T n-1 T i indicates p i wants to try to enter the critical section  E 0,…, E n-1 E i indicates p i wants to exit the critical section  outputs:  C 0,…,C n-1 C i indicates p i may now enter the critical section  R i,…,R n-1 R i indicates p i may now enter the remainder section

7. Mutual Exclusion Example CSCE 668Set 14: Simulations 7 Mutual Exclusion T1T1 C1C1 E1E1 R1R1 p1p1 p0p0 p2p2 T2T2 C2C2 E2E2 R2R2 T0T0 C0C0 E0E0 R0R0

8. Mutual Exclusion Example (cont'd) CSCE 668Set 14: Simulations 8  a sequence  of inputs and outputs is allowable iff, for each i,   |i cycles through T i, C i, E i, R i each proc cycles through trying, critical, exit, and remainder sections in that order  whenever C i occurs, most recent preceding input or output for any j ≠ i is not C j only one process is in the critical section at a time

9. Mutual Exclusion Example (cont'd) CSCE 668Set 14: Simulations 9  T 1 T 2 C 1 T 3 E 1 C 3 R 1 E 3 R 3  allowable  T 1 T 2 C 1 T 3 C 3 E 1 R 1 E 3 R 3  not allowable

10. Communication Systems So Far CSCE 668Set 14: Simulations 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.

11. Different Kinds of Communication Systems CSCE 668Set 14: Simulations 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

12. What Kinds of Simulations? CSCE 668Set 14: 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

13. New Way to Model Communication Systems CSCE 668Set 14: Simulations 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

14. Asynchronous Point-to-Point Message Passing Example CSCE 668Set 14: Simulations 14 Interface is:  inputs: send i (M)  models p i sending set of msgs M  each msg indicates sender and recipient (must be consistent with assumed topology)  outputs: recv i (M)  models p i receiving set of msgs M  each msg in M must have p i as its recipient

15. Asynch MP Example (cont'd) CSCE 668Set 14: Simulations 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

16. Asynchronous Broadcast Example CSCE 668Set 14: Simulations 16  Inputs: bc-send i (m)  an input to the broadcast service  p i wants to use the broadcast service to send m to all the procs  Outputs: bc-recv i (m, j )  an output of the broadcast service  broadcast service is delivering msg m, sent by p j, to p i

17. Asynch Bcast Example (cont'd) CSCE 668Set 14: Simulations 17  A sequence of inputs and outputs (bc-sends and bc- recvs) is allowable iff there exists a mapping  from each bc-recv i (m,j) event to an earlier bc-send j (m) event s.t.   is well-defined: every msg bc-recv'ed was previously bc- sent   restricted to bc-recv i events, for each i, is one-to-one: no msg is bc-recv'ed more than once at any single proc.   restricted to bc-recv i events, for each i, is onto: every msg bc-sent is received at every proc.

18. Processes CSCE 668Set 14: Simulations 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

19. Modeling Process Stack at a Node CSCE 668Set 14: Simulations 19 layer 1layer 2layer 3 environment communication system modeled as a problem spec (interface & allowable sequences) modeled as a problem spec (interface & allowable sequences) modeled as state machines communicate via appropriate primitives: shared events

20. Intra-Node Communication Pattern CSCE 668Set 14: Simulations 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)

21. Definition of Execution CSCE 668Set 14: Simulations 21 Sequence C 0 e 1 C 1 e 2 C 2 … of alternating configurations and events s.t.  C 0 is an initial configuration  event e i is enabled in C i-1 (there is a transition from the state(s) of the relevant process(es) in C i-1 labeled e i )  state components of processes change according to the transition functions for e i  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

22. Definition of Admissible Execution CSCE 668Set 14: Simulations 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.

23. Proper Behavior of Communication System CSCE 668Set 14: Simulations 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

24. Proper Behavior of Environment CSCE 668Set 14: Simulations 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.

25. Simulations CSCE 668Set 14: Simulations 25 System C 1 simulates system C 2 if there is a set of processes, one per node, called Sim s.t. 1. top interface of Sim is the interface of C 2 2. bottom interface of Sim is the interface of C 1 3. For every admissible execution  of Sim, the restriction of  to the interface of C 2 is allowable for C 2 (according to its problem spec).

26. Simulations CSCE 668Set 14: Simulations 26 Sim Sim 0 C 2 inputs C 2 outputs C 1 inputs C 1 outputs C1C1 Sim n-1 C 2 inputs C 2 outputs C 1 inputs C 1 outputs … C2C2 If user of C 2 behaves properly and if C 1 behaves properly, then Sim ensures that user of C 2 thinks it is really using C 2 (and not C 1 plus a simulation layer)