Read-Modify-Writable Snapshots from Read/Write operations

TL;DR

This work investigates whether Read-Modify-Writable snapshots can be implemented using only read/write operations in asynchronous, fault-prone shared-memory systems. It delivers two read/write RMWable snapshot algorithms: a solo-updater for scenarios without concurrent updates and a general concurrent-updater for the standard concurrent environment, plus an adaptation for unbounded concurrency; all rely on a Collect(MEM) primitive and decouple MEM from the Update/Scan logic. The proposed solutions are proven linearizable and wait-free, extending snapshot capabilities to collections of arbitrarily readable MEM[k] objects without requiring powerful primitives like compare&swap or LL/SC. The results have practical significance for checkpointing and snapshotting existing concurrent algorithms, and they inform the design space for coordination-efficient, read/write-only distributed snapshot techniques in both finite and unbounded process models.

Abstract

In the context of asynchronous concurrent shared-memory systems, a snapshot algorithm allows failure-prone processes to concurrently and atomically write on the entries of a shared array MEM , and also atomically read the whole array. Recently, Read-Modify-Writable (RMWable) snapshot was proposed, a variant of snapshot that allows processes to perform operations more complex than just read and write, specifically, each entry MEM[k] is an arbitrary readable object. The known RMWable snapshot algorithms heavily rely on powerful low-level operations such as compare&swap or load-link/store-conditional to correctly produce snapshots of MEM. Following the large body of research devoted to understand the limits of what can be solved using the simple read/write low-level operations, which are known to be strictly weaker than compare&swap and load-link/store-conditional, we explore if RMWable snapshots are possible using only read/write operations. We present two read/write RMWable snapshot algorithms, the first one in the standard concurrent shared-memory model where the number of processes n is finite and known in advance, and the second one in a variant of the standard model with unbounded concurrency, where there are infinitely many processes, but at any moment only finitely many processes participate in an execution.

Figures (6)

• Figure 1: A linearizable stack execution for three processes, $T_1, T_2$ and $T_3$. Horizontal double-headed arrows denote the time that elapses between the invocation and response of a thread's operation. The linearization points induce a sequential execution that is valid for the stack object.
• Figure 2: A solo-updater algorithm. Local algorithm for process $p_i$. Local variables of the process are denoted in lowercase letters. While the algorithm without the lines marked in red is only lock-free, the algorithm with those lines is wait-free.
• Figure 3: If $MEM$ is modified at most once during a collect, the collect is indeed a snapshot. In the example, $MEM$ has four objects and while the collect is taken, a process performs an operation in $M[3]$, changing the state of the object from $s_3$ to $s'_3$. Step $MEM[k].read()$ returning $s$ is simply denoted $MEM[k]:s$. If the collect reads $M[3]$ before $M[3]$ is modified, then the values obtained by the collect, $[s_1,s_2,s_3,s_4]$, coincide with the state of the objects of $MEM$ during the interval that goes from the first read of the collect to the read of $M[3]$; if the collect reads $M[3]$ after the modification, the collect obtains the states in $MEM$, $[s_1,s_2,s'_3,s_4]$, during the interval that goes from the read of $M[3]$ to the last read of the collect. In any case, the collect corresponds to a snapshot of the memory.
• Figure 4: A concurrent-updater algorithm. Local algorithm for process $p_i$. Local variables are denoted in lowercase letters. While the algorithm without the lines marked in red is only lock-free, the algorithm with those lines is wait-free. In the lock-free algorithm, the goto command in line \ref{['B18']} restarts the while loop, as line \ref{['B22']} is not part of the algorithm.
• Figure 5: If $MEM$ is modified two or more times during a collect, the collect might not be a snapshot. In the example, $MEM$ has four objects and while the collect is taken, objects $MEM[2]$ and $MEM[3]$ are modified, changing states from $s_2$ and $s_3$ to $s'_2$ and $s'_3$, respectively. Step $MEM[k].read()$ returning $s$ is simply denoted $MEM[k]:s$. Observe that the values obtained by the collect, $[s_1,s_2,s'_3,s_4]$, do not correspond to the object states in $MEM$ at any point in time, hence it is not a snapshot.

Theorems & Definitions (10)

• theorem thmcountertheorem
• proof
• theorem thmcountertheorem
• proof
• theorem thmcountertheorem
• proof
• theorem thmcountertheorem
• proof
• theorem thmcountertheorem
• proof