Synchronizers Outline motivation principles and definitions implementation rules and phases complexity measures synchronizers  - pulse time is optimal, message complexity is high  - message complexity is optimal, pulse time is high

Motivation algorithms for synchronous networks are easier to design, analyze and debug than in asynchronous networks idea: design the algorithm in synchronous network and transform it to asynchronous synchronizer – general approach to the transformation ASYNC is used in this section synchronizers may be less efficient than ad hoc coding directly in ASYNC but turns out to be “pretty good”: finds solutions in ASYNC better than known before

Principles given a synchronizer  and a synchronous algorithm S it is possible to combine them to yield an asynchronous program A= (S) that is equivalent to S A – combined algorithm consisting of two components having their own local variables and message types original component corresponding to S synchronization component corresponding to  pulse variable – Pv maintained by each process v and stores the serial pulse being simulated (different processes may simulate different pulses) pulse generation – the process of updating pulse variable pulse compatibility – the original message is sent and received during the same pulse Lemma 6.1.3 – a synchronizer that guarantees pulse compatibility is correct correctness is defined in terms of equivalence of executions

Implementation rules readiness property: a process is ready for the next pulse if it received all original messages sent by its neighbors in the previous pulse readiness rule: a process generates next pulse only when it finishes with previous pulse original actions and satisfies readiness property readiness rule prohibits receiving messages “from the past” but not “from the future” delaying rule: the process delays delivery of the messages from subsequent pulses Lemma 6.1.4: a synchronizer imposing readiness and delaying rules guarantees pulse compatibility from Lemma 6.1.2 Corollary 6.1.5: such synchronizer is correct

Implementation phases readiness is easy to guarantee if S has complete communication: each process sends a message to every neighbor at every pulse What to do if partial communication? Phase A: each process w sends original messages, receivers acknowledge. w is safe wrt a pulse if it got acks for all original messages it sent during this pulse Phase B: inform neighbors that the process is safe Lemma 6.1.6: if every neighbor of w is safe with respect to a pulse, w is ready for next pulse

Alternative implementation phases Notice that when a process w is ready for next phase its neighbor v may not be ready just safe. v is not ready because its own neighbor u is not safe hence when w sends original messages of the next pulse to v, v has to delay them due to delay rule alternatively, pulse increase is divided into two stages a process may receive messages of the next pulse but not send a process may send messages of the next pulse a process is enabled if its every neighbor is ready enabling rule: a process is allowed to send original messages of the pulse only when it is enabled for this pulse Lemma 6.1.7: a synchronizer imposing readiness and enabling rules is correct Phase C: inform each process when its neighbors are ready

Complexity measures consider synchronizer v v needs to spend some resources before it starts running Timeinit(v) – time requirements for initialization Messageinit(v) – message requirements for initialization v imposes certain overhead wrt S at each step Timepulse(v) – the earliest time all processes change to pulse p from pulse p-1 Messagepulse(v) – message overhead incurred by v in one pulse

Synchronizer  when process is safe – it sends messages to every neighbor Lemma 6.3.1  is correct complexity initialization can be done by the flooding algorithm Timeinit() = O(|E|) Messageinit() = O(Diam(G)) step Timepulse() = O(1) – from pulse to pulse it takes constant number of steps for each process Messagepulse() = O(|E|)

Synchronizer  there is a rooted spanning tree T convergecast safety information up the tree and broadcast it back Lemma 6.3.3  is correct complexity initialization can be done by setting up a BFS tree by distributed Bellman-Ford Timeinit() = O(n|E|) Messageinit() = O(Diam(G)) step – costs involved in a single convergecast and broadcast Timepulse() = O(Diam(G)) Messagepulse() = O(n)