Synchronizer Implementation in Synchronous Networks
90 likes | 182 Vues
Explore motivations, principles, and complexities of synchronizers in transforming synchronous algorithms to asynchronous, with detailed implementation rules and phases. Understand pulse time optimization and message complexity balancing techniques.
Synchronizer Implementation in Synchronous Networks
E N D
Presentation Transcript
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)