Several sets of slides by Prof. Jennifer Welch will be used in this course. The slides are mostly identical to her slides, with some minor changes. Set 1: Introduction 1

DISTRIBUTED ALGORITHMS Spring 2014 Prof. Jennifer Welch CSCE 668 Set 1: Introduction 2

Distributed Systems Set 1: Introduction 3  Distributed systems have become ubiquitous:  share resources  communicate  increase performance speed fault tolerance  Characterized by  independent activities (concurrency)  loosely coupled parallelism (heterogeneity)  inherent uncertainty

Uncertainty in Distributed Systems Set 1: Introduction 4  Uncertainty comes from  differing processor speeds  varying communication delays  (partial) failures  multiple input streams and interactive behavior

Reasoning about Distributed Systems Set 1: Introduction 5  Uncertainty makes it hard to be confident that system is correct  To address this difficulty:  identify and abstract fundamental problems  state problems precisely  design algorithms to solve problems  prove correctness of algorithms  analyze complexity of algorithms (e.g., time, space, messages)  prove impossibility results and lower bounds

Potential Payoff of Theoretical Paradigm Set 1: Introduction 6  careful specifications clarify intent  increased confidence in correctness  if abstracted well then results are relevant in multiple situations  indicate inherent limitations  cf. NP-completeness

Application Areas Set 1: Introduction 7  These areas have provided classic problems in distributed/concurrent computing:  operating systems  (distributed) database systems  software fault-tolerance  communication networks  multiprocessor architectures  Newer application areas:  cloud computing  mobile computing, …

Basic Models Set 1: Introduction 8  Introduce two basic communication models:  message passing  shared memory  and two basic timing models:  synchronous  asynchronous

Basic Models Set 1: Introduction 9 Message passing Shared memory synchronous asynchronous Yes No Yes (Synchronous shared memory model is PRAM)

Relationship of Theory to Practice Set 1: Introduction 10  time-shared operating systems: issues relating to (virtual) concurrency of processes such as  mutual exclusion  deadlock also arise in distributed systems  MIMD multiprocessors:  no common clock => asynchronous model  common clock => synchronous model  loosely coupled networks, such as Internet, => asynchronous model

Relationship of Theory to Practice Set 1: Introduction 11  Failure models:  crash: faulty processor just stops. Idealization of reality.  Byzantine (arbitrary): conservative assumption, fits when failure model is unknown or malicious  self-stabilization: algorithm automatically recovers from transient corruption of state; appropriate for long-running applications

Message-Passing Model Set 1: Introduction 12  processors are p 0, p 1, …, p n-1 (nodes of graph)  bidirectional point-to-point channels (undirected edges of graph)  each processor labels its incident channels 1, 2, 3,…; might not know who is at other end

Message-Passing Model Set 1: Introduction p3p3 p2p2 p0p0 p1p1

Modeling Processors and Channels Set 1: Introduction 14  Processor is a state machine including  local state of the processor  mechanisms for modeling channels  Channel directed from processor p i to processor p j is modeled in two pieces:  outbuf variable of p i and  inbuf variable of p j  Outbuf corresponds to physical channel, inbuf to incoming message queue

Modeling Processors and Channels Set 1: Introduction 15 inbuf[1] p 1 's local variables outbuf[1] inbuf[2] outbuf[2] p 2 's local variables Pink area (local vars + inbuf) is accessible state for a processor.

Configuration Set 1: Introduction 16  Vector of processor states (including outbufs, i.e., channels), one per processor, is a configuration of the system  Captures current snapshot of entire system: accessible processor states (local vars + incoming msg queues) as well as communication channels.

Deliver Event Set 1: Introduction 17  Moves a message from sender's outbuf to receiver's inbuf; message will be available next time receiver takes a step p1p1 p2p2 m 3 m 2 m 1 p1p1 p2p2

Computation Event Set 1: Introduction 18  Occurs at one processor  Start with old accessible state (local vars + incoming messages)  Apply transition function of processor's state machine; handles all incoming messages  End with new accessible state with empty inbufs, and new outgoing messages

Computation Event Set 1: Introduction 19 cd e old local state a new local state b pink indicates accessible state: local vars and incoming msgs white indicates outgoing msg buffers

Execution Set 1: Introduction 20  Format is config, event, config, event, config, …  in first config: each processor is in initial state and all inbufs are empty  for each consecutive (config, event, config), new config is same as old config except:  if delivery event: specified msg is transferred from sender's outbuf to receiver's inbuf  if computation event: specified processor's state (including outbufs) change according to transition function

Admissibility Set 1: Introduction 21  Definition of execution gives some basic "syntactic" conditions.  usually safety conditions (true in every finite prefix)  Sometimes we want to impose additional constraints  usually liveness conditions (eventually something happens)  Executions satisfying the additional constraints are admissible. These are the executions that must solve the problem of interest.  Definition of “admissible” can change from context to context, depending on details of what we are modeling

Asynchronous Executions Set 1: Introduction 22  An execution is admissible for the asynchronous model if  every message in an outbuf is eventually delivered  every processor takes an infinite number of steps  No constraints on when these events take place: arbitrary message delays and relative processor speeds are not ruled out  Models reliable system (no message is lost and no processor stops working)

Example: Flooding Set 1: Introduction 23  Describe a simple flooding algorithm as a collection of interacting state machines.  Each processor's local state consists of variable color, either red or green  Initially:  p 0 : color = green, all outbufs contain M  others: color = red, all outbufs empty  Transition: If M is in an inbuf and color = red, then change color to green and send M on all outbufs

Example: Flooding Set 1: Introduction 24 p1p1 p0p0 p2p2 MM p1p1 p0p0 p2p2 M M deliver event at p 1 from p 0 computation event by p 1 deliver event at p 2 from p 1 p1p1 p0p0 p2p2 M M MM p1p1 p0p0 p2p2 M M computation event by p 2

Example: Flooding (cont'd) Set 1: Introduction 25 deliver event at p 1 from p 2 computation event by p 1 deliver event at p 0 from p 1 etc. to deliver rest of msgs p1p1 p0p0 p2p2 M M M M p1p1 p0p0 p2p2 M M M M p1p1 p0p0 p2p2 M M M p1p1 p0p0 p2p2 M M M

Nondeterminism Set 1: Introduction 26  The previous execution is not the only admissible execution of the Flooding algorithm on that triangle.  There are several, depending on the order in which messages are delivered.  For instance, the message from p 0 could arrive at p 2 before the message from p 1 does.

Termination Set 1: Introduction 27  For technical reasons, admissible executions are defined as infinite.  But often algorithms terminate.  To model algorithm termination, identify terminated states of processors: states which, once entered, are never left  Execution has terminated when all processors are terminated and no messages are in transit (in inbufs or outbufs)

Termination of Flooding Algorithm  Define terminated processor states as those in which color = green. Set 1: Introduction 28

Synchronous Message Passing Systems Set 1: Introduction 29  An execution is admissible for the synchronous model if it is an infinite sequence of "rounds"  What is a "round"?  It is a sequence of deliver events that move all messages in transit into inbuf's, followed by a sequence of computation events, one for each processor.

Synchronous Message Passing Systems Set 1: Introduction 30  The new definition of admissible captures lockstep unison feature of synchronous model.  This definition also implies  every message sent is delivered  every processor takes an infinite number of steps.  Time is measured as number of rounds until termination.

Example of Synchronous Model Set 1: Introduction 31  Suppose flooding algorithm is executed in synchronous model on the triangle.  Round 1:  deliver M to p 1 from p 0  deliver M to p 2 from p 0  p 0 does nothing (as it has no incoming messages)  p 1 receives M, turns green and sends M to p 0 and p 1  p 2 receives M, turns green and sends M to p 0 and p 1

Example of Synchronous Model Set 1: Introduction 32  Round 2:  deliver M to p 0 from p 1  deliver M to p 0 from p 2  deliver M to p 1 from p 2  deliver M to p 2 from p 1  p 0 does nothing since its color variable is already green  p 1 does nothing since its color variable is already green  p 2 does nothing since its color variable is already green

Example of Synchronous Model Set 1: Introduction 33 p1p1 p0p0 p2p2 M MM M p1p1 p0p0 p2p2 MM p1p1 p0p0 p2p2 round 1 events round 2 events