1 / 20

Asynchronous Exclusive Selection

Asynchronous Exclusive Selection. Bogdan Chlebus , U. Colorado Darek Kowalski , U. Liverpool. Model and Problem. 9. 2. 17. 11. 3. 12. 1. 28. 27. 8. 4. READ. 5. WRITE. 14. 7. 6. 15. 13. 1. processes. registers. Model Details. PROCESSES: n processes

cmoody
Télécharger la présentation

Asynchronous Exclusive Selection

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. Asynchronous Exclusive Selection BogdanChlebus, U. Colorado Darek Kowalski, U. Liverpool

  2. Model and Problem 9 2 17 11 3 12 1 28 27 8 4 READ 5 WRITE 14 7 6 15 13 1 processes registers

  3. Model Details PROCESSES: • n processes • unique ids from {1,...,N} • asynchronous • prone to crash failures REGISTERS: • r registers • unique ids from {1,...,r} • read/write • store O(log N) bits each PROBLEMS: Assigning exclusive integers to processes

  4. Plan Example 1: Renaming Example 2: Store&Collect Example 3: Unbounded Naming

  5. Example 1: Renaming Problem definition: • k ≤ n processes contend to acquire unique integers as new names in a smaller range {1,...,M} Complexity measures: • Max number of local steps per process • Length of the new name interval M • Number r of registers used

  6. Competing for Register Pair of registers is more useful than single ones Splitter(R): • If one process contends then it wins R • R can be won by at most one contending process • If there is more than one contending process then at least two different outputs are achieved • Compete-for-Register(R): • If one process contends then it wins R • R can be won by at most one contending process

  7. ... Main Technique 8 28 7 27 6 5 17 4 13 3 5 2 1 1 processes registers

  8. Main Technique: Majority Renaming (l,N)-Majority-Renaming (MR) Problem: at least half of l contending processes acquire new unique names in the interval {1,...,M}. We implement MR for any l, N, and for M=12e7l log(N/l) We need: • Bipartite graph G between set of processes and set of registers such that: • Input degree is 4 log(N/l) • A majority of contending processes have unique neighbours (i.e., no other contending process has it as a neighbour)

  9. From Majority Renaming to Renaming • Assume known k known N • Let Si, for i=0,1,...,lg k, be mutually disjoint sets of registers, s.t., |Si|=12e7(k/2i) log(2iN/k) • Solve (k/2i,N)-Majority-Renaming for i=0,1,...,lg k • For ith execution, use set Si of registers COMPLEXITY of algorithm Basic-Rename(k,N): • Local steps: O(log k log N) • M, r = O(k log(N/k)), i.e., M = 24e7k log(N/k)

  10. Cascade Renaming • Assume known k known N • Execute Basic-Rename(k,Nj), for j=0,1,...,j* • N0 := N • Nj := 24e7klog(Nj-1/k), for j>0, until Nj ≤ e14k COMPLEXITY of algorithm Cascade-Rename(k,N): • Local steps: O(log k (log N + log k loglog N)) • M ≤ e14k • r = O(k log(N/k))

  11. Relaxing parameters k and N • Known k unknown N • Local steps: O(k) • M = 2k-1 • r = O(k2) • Unknown k known N • Local steps: O(log2k (log N + log k loglog N)) • M = O(k) • r = O(n log(N/n)) • Unknown k, N MA AF AM • Local steps: O(k) O(k) O(k log k) O(k2) • M = 8k – lg k -1 O(k2) O(k) 2k-1 • r = O(n2) O(n2) O(n2) O(n2)

  12. Example 2: Store&Collect • Problem definition: some arbitrary k processes repeatedly execute operations Store and Collect • Store: updates the value that the process wants to be collected by others • Collect: learns all the values proposed most recently by other processes, one value per process • Complexity Measures: • Max number of local steps per process • Number r of registers used

  13. From Renaming to Store&Collect • Organize registers into consecutive intervals of lengths 2,4,8,... • Associate a control register with every interval First Store operation (of process p): • Set control regs of intervals of size smaller than p into used • Acquire a new name i using renaming algorithm and deposit the value in the register with the name i located in the shortest interval of length not smaller than p Collect operation: • Collect all values from consecutive intervals until the first empty control register occurs

  14. Store&Collect results • N,k – known: • Store time: O(log k (log N + log k loglog N)) • Collect time: O(k) • Number of registers: O(k log(N/k)) ... • N,k – unknown: • Store/Collect time: O(k) • Number of registers: O(n2) (different approach: Afek, De Levie, DC 2007)

  15. Lower Bounds Any wait-free solution of Renaming requires 1 + min{k-1, log2r (N/2M)} local steps in the worst case. Space-efficient solution: O(k) registers Any wait-free space-efficient solution of Store operation in Store&Collect requires (min{k, logr (N/k)}) local steps in the worst case.

  16. Example 3: Unbounded Naming Problem: • Infinite number of registers dedicated to depositing • Fairly distributed deposit requests (each process eventually receives a new value to deposit) • Deposit operation must be acknowledged Measure: • Number of registers never used for depositing Naive solution (infinite number of unused registers): • Process p deposits in consecutive registers congruent to p modulo N

  17. Repository Repository: concurrent data structure, s.t., each process can deposit consecutive values in dedicated registers to guarantee: Persistence – for any register R dedicated for depositing, after an ack(R) event, no value is ever written to R Non-blocking – each time at least one non-faulty process wants to deposit a value, then eventually the value gets deposited

  18. Implementing a Repository Minimizing the number of unused registers (n-1) • Each process p maintains (locally): • list Lp of 2n-1 register numbers (available for deposits) • next possibly empty register Ap • Atomic snapshot object of n SWMR registers • Verification procedure: process p verifies list Lp by reading consecutive registers, removing non-empty ones and searching for a new one (starting from Ap) • Choosing by rank: a process of rank k among other acquiring processes selects kth register from its list and verifies, using snapshot, if it is unique

  19. Implementing a Repository cont. Wait free implementation with n(n-1) deposit-free registers • Array Help[1..n,1..n] of shared registers • Two parallel threads intertwined: • Verification: process p keeps reading Help[p,*] in a cyclic fashion, every Help[p,q] = null is replaced by new name obtained from the previous algorithm • Depositing: process p keeps reading Help[*,p] in a cyclic fashion, until finding q s.t. Help[q,p] = x ≠ null, deposits in Rx and writes null to Help[q,p]

  20. Conclusion • We presented a variety of selection techniques and their applications • There is enough evidence that new methods and applications are needed • How to reduce the number of registers: • Quadratic number of registers is used in most of the presented applications

More Related