Asynchronous Exclusive Selection Bogdan Chlebus, U. Colorado Darek Kowalski, U. Liverpool

Model and Problem 17 READ WRITE processesregisters

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

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

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

Competing for Register 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 Pair of registers is more useful than single ones

Main Technique processes registers

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=12e 7 l 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)

From Majority Renaming to Renaming Assume known k known N Let S i, for i=0,1,...,lg k, be mutually disjoint sets of registers, s.t., |S i |=12e 7 (k/2 i ) log(2 i N/k) Solve (k/2 i,N)-Majority-Renaming for i=0,1,...,lg k – For i th execution, use set S i 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 = 24e 7 k log(N/k)

Cascade Renaming Assume known k known N Execute Basic-Rename(k,N j ), for j=0,1,...,j* – N 0 := N – N j := 24e 7 klog(N j-1 /k), for j>0, until N j ≤ e 14 k COMPLEXITY of algorithm Cascade-Rename(k,N): Local steps: O(log k (log N + log k loglog N)) M ≤ e 14 k r = O(k log(N/k))

Relaxing parameters k and N Known k unknown N – Local steps: O(k) – M = 2k-1 – r = O(k 2 ) Unknown k known N – Local steps: O(log 2 k (log N + log k loglog N)) – M = O(k) – r = O(n log(N/n)) Unknown k, NMAAFAM – Local steps: O(k)O(k)O(k log k)O(k 2 ) – M = 8k – lg k -1O(k 2 )O(k)2k-1 – r = O(n 2 )O(n 2 )O(n 2 )O(n 2 )

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

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

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(n 2 ) (different approach: Afek, De Levie, DC 2007)

Lower Bounds Any wait-free solution of Renaming requires 1 + min{k-1, log 2r (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, log r (N/k)}) local steps in the worst case.

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

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

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

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 R x and writes null to Help[q,p]

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