Asynchronous Exclusive Selection

```Asynchronous Exclusive Selection
Darek Kowalski, U. Liverpool
Model and Problem
2
9
17
12
1
11
3
28
27
4
8
WRITE
5
14
7
15
6
13
1
processes
registers
Model Details
PROCESSES:
REGISTERS:
• n processes
• r registers
• unique ids from {1,...,N} • unique ids from {1,...,r}
• asynchronous
• prone to crash failures • 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
Pair of registers is more useful than single ones
Splitter(R):
Compete-for-Register(R):
• If one process contends
• If one process contends
then it wins R
then it wins R
• R can be won by at most
• R can be won by at most
one contending process
one contending process
• If there is more than one
contending process then at
least two different outputs
are achieved
.
.
.
Main Technique
8
28
7
27
6
17
5
13
4
3
5
2
1
1
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=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)
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)
• 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
• Local steps: O(log k (log N + log k loglog N))
• M ≤ e14k
• r = O(k log(N/k))
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
– Local steps:
– M=
– r=
MA
O(k)
8k – lg k -1
O(n2)
AF
AM
O(k) O(k log k)
O(k2) O(k)
O(n2) O(n2)
O(k2)
2k-1
O(n2)
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(n2)
(different approach: Afek, De Levie, DC 2007)
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.
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 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
Implementing a Repository cont.
Wait free implementation with n(n-1) deposit-free registers
• Array Help[1..n,1..n] of shared registers
– 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]
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
```