90 likes | 169 Views
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.
E N D
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 programA= (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 processv 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.2Corollary 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)