1 / 14

Distributed Algorithms (22903)

This presentation discusses the concept of atomic snapshot objects and their applications in distributed computing. It covers the sequential specification, algorithmic ideas, simulation techniques, and a wait-free simulation of atomic snapshots. It also explores the renaming problem and presents a wait-free renaming algorithm. The algorithm is proven to be correct with a maximum of 2n-1 names required.

reedc
Download Presentation

Distributed Algorithms (22903)

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. DistributedAlgorithms (22903) The Atomic Snapshot Object And Applications Lecturer: Danny Hendler This presentation is based on the book “Distributed Computing” by Hagit attiya & Jennifer Welch.

  2. Atomic snapshot objects • Each process has a SWMR register, which we call a segment • A process may obtain an ‘atomic snapshot’ of all segments. • Atomic Snapshot sequential specification • Two operations are supported: • Updatei(d), by pi, updates pi’s segment to value d. • Scan, returns a vector V, where V is an n-element vector called a view (with a value for each segment). V[i] must return the value of the latest Updatei operation (or the initial value if there were none) Scan returns a snapshot of the segments array that existed at some point during the execution!

  3. A trivial (and wrong) algorithm Initially segment[i]=vi • Updatei(S, v) • Segment[i]=v • Scani(S) • for i=1 to n • tmp[i]=Segment[i] • return < tmp[1], …, tmp[n] > Why is this algorithm incorrect?

  4. Atomic snapshot simulation:key algorithmic ideas (Afek, Attiya, Dolev, Gafni, Merritt, Shavit, 1993) • A scan collects all segments twice (double collect). • If the two collects are identical, they are a legal view What if segments change while being collected? • Then we try again and again until some segment undergoes “enough” changes (we can be sure its last update started after our scan) • We then use a view embedded in that update • We use timestamps to distinguish different writes of same value

  5. A wait-free simulation of atomic snapshot Initially segment[i].ts=0, segment[i].data=vi, segment[i].view=<v0, …, vn-1> • Updatei(S, d) • view:=scan() • Segment[i]=<segment[i].ts+1, d, view> • Scani(S) • for all j <> i c[j]=Segment[j] • while true do • for all j a[j] = Segment[j] • for all j b[j] = Segment[j] • if, for all j a[j]=b[j] ; Comparison includes timestamp! • return <b[0].data, …, b[n-1].data> ; Direct scan • else if, for some j ≠ i, b[j].ts - c[j].ts ≥ 2 • return b[j].view ; Indirect scan

  6. Linearization order • A direct scan is linearized immediately after the last read of its first collect • An indirect scan is linearized at the same point as the direct scan whose view it borrowed. • An update is linearized when it writes to its segment.

  7. A proof that the algorithm for atomic snapshot is wait-free and linearizable

  8. The Renaming Problem • Processes start with unique names from a large domain • Processes should pick new names that are still distinct but that are from a smaller domain • Motivation: Suppose original names are serial numbers (many digits), but we'd like the processes to do some kind of time slicing based on their ids

  9. Renaming Problem Definition Termination: Eventually every nonfaulty proc pidecides on a new name yi Uniqueness:If pi and pj are distinct nonfaulty procs, then yi ≠ yj. Anonymity:Processes cannot directly use their index, only their name.

  10. Performance of Renaming Algorithm • New names should be drawn from {1,2,…,M}. • We would like M to be as small as possible. • Uniqueness implies M must be at least n. • Due to the possibility of failures, M will actually be larger than n.

  11. Wait-free renaming algorithm • Processes communicate via snapshot object • Each process iteratively stores its original name and (suggested) new name • If the name suggested by p is taken, it next suggests the k’th free name, where k is its original rank

  12. Wait-free renaming algorithm (cont’d) Shared:Snapshot S, each entry is of the form <x,s>, initially emptyLocal:int oldName ;this is pi’s original nameint newName;this is pi’s suggested name, initially 1 • Program for process i • newName := 1 ;Maybe I can get the smallest name • While true do ;While haven’t fixed my new name • S.updatei(<oldName,newName>) ;Announce new suggestion • <x0,s0>,…,<xn-1,sn-1> := S.scan() ;take a snapshot • if (newName = sj for some j ≠ i) ;ouch, there’s a clash ; select the r’th free name, where r is my rank • let r be the rank of oldName in {xj ≠ empty | 0≤j≤n-1} • let newName be r’th integer not in {sj ≠ empty | 0≤j ≠ i ≤n-1} • else • return newName

  13. The algorithm is a correct wait-free implementation of renaming that requires at most 2n-1 names

  14. Renaming Results • Algorithm for wait-free case (f = n - 1) with M = n + f = 2n - 1. • Algorithm for general f with M = n + f. • Lower bound that M must be at least n + 1, for the wait-free case. • Proof similar to impossibility of wait-free consensus • Stronger lower bound that M must be at least n + f, if f is the number of possible failures • Proof uses algebraic topology and is related to lower bound for set consensus

More Related