1 / 19

Session - 7

Session - 7. Constructing a DFS Spanning Tree without a Specified Root. Constructing a DFS Spanning Tree without a Specified Root. Problem: Building a ST when there is no distinguished node Assumption: Nodes have unique identifiers Description :

wtownsend
Télécharger la présentation

Session - 7

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session - 7

  2. Constructing a DFS Spanning Tree without a Specified Root

  3. Constructing a DFS Spanning Tree without a Specified Root Problem: Building a ST when there is no distinguished node Assumption: Nodes have unique identifiers Description : Each processor wakes up simultaneously attempt to build a DFS tree with it self as the root using Algorithm3 If two DFS trees try to connect to the same node (not necessarily at same time) The node will join the DFS tree whose root has the higher identifier

  4. Constructing a DFS Spanning Tree without a Specified Root Idea: Each node keeps the maximal id it has seen so far in a variable leader The initial value of leader smaller than any id When a node wakes up, spontaneously, sets its leader to its own identifier and send a DFS msg carrying its identifier When a node receives a DFS msg with identifier ‘ y’ compare ‘y’ and leader If y > leader then ‘y’ might be the DFS of the processor with maximal id

  5. Constructing a DFS Spanning Tree without a Specified Root Idea: Now node changes ‘y’ to become leader Sets its parent variable to be the node from which msg was received and continuous the DFS with id ‘y’ If y = leader then the node already belongs to the ST If y < leader then ‘y’ is smaller than the max id seen so far, in this case, no msg is sent Stalls the DFS construction with id ‘y’ Eventually, a DFS msg carrying the id leader (or a larger id) will arrive at the node with id ‘y’ and connect to its tree.

  6. A Formal Model for Simulations

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

  8. Problem Specifications So Far • 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

  9. New Way to Specify Problems 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.

  10. A New Way to Specify Problems P outputs inputs

  11. Mutual Exclusion Example • inputs: • T0, …, Tn-1 • Ti indicates pi wants to try to enter the critical section • E0,…, En-1 • Eiindicates pi wants to exit the critical section • outputs: • C0,…,Cn-1 • Ci indicates pi may now enter the critical section • Ri,…,Rn-1 • Ri indicates pi may now enter the remainder section

  12. Mutual Exclusion Example p1 T1 C1 E1 R1 T2 Mutual Exclusion T0 C2 C0 p2 E2 p0 E0 R2 R0

  13. Mutual Exclusion Example (cont'd) • a sequence  of inputs and outputs is allowable iff, for each i, • |i cycles through Ti, Ci, Ei, Ri • each proc cycles through trying, critical, exit, and remainder sections in that order • whenever Cioccurs, most recent preceding input or output for any j ≠ i is not Cj • only one process is in the critical section at a time

  14. Mutual Exclusion Example (cont'd) • T1T2 C1T3 E1C3 R1E3 R3 • allowable • T1T2 C1T3C3 E1 R1E3 R3 • not allowable

  15. Communication Systems So Far • 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.

  16. Different Kinds of Communication Systems • 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

  17. What Kinds of Simulations? How to provide broadcast (send to all, with different reliability and ordering guarantees) on top of point-to-point message passing (send to one) 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

  18. New Way to Model Communication Systems • 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

More Related