Update Consistency for Wait-free Concurrent Objects

TL;DR

This paper introduces update consistency, a new data replication criterion that ensures convergence of shared object states based on updates, balancing consistency and fault tolerance in large-scale distributed systems.

Contribution

It formalizes update consistency, proving it is stronger than eventual consistency and universally implementable even with node crashes.

Findings

Update consistency guarantees convergence based on updates.

It is stronger than eventual consistency.

Any object can be implemented under update consistency in crash-prone systems.

Abstract

In large scale systems such as the Internet, replicating data is an essential feature in order to provide availability and fault-tolerance. Attiya and Welch proved that using strong consistency criteria such as atomicity is costly as each operation may need an execution time linear with the latency of the communication network. Weaker consistency criteria like causal consistency and PRAM consistency do not ensure convergence. The different replicas are not guaranteed to converge towards a unique state. Eventual consistency guarantees that all replicas eventually converge when the participants stop updating. However, it fails to fully specify the semantics of the operations on shared objects and requires additional non-intuitive and error-prone distributed specification techniques. This paper introduces and formalizes a new consistency criterion, called update consistency, that requires the state of a replicated object to be consistent with a linearization of all the updates. In other words, whereas atomicity imposes a linearization of all of the operations, this criterion imposes this only on updates. Consequently some read operations may return out-dated values. Update consistency is stronger than eventual consistency, so we can replace eventually consistent objects with update consistent ones in any program. Finally, we prove that update consistency is universal, in the sense that any object can be implemented under this criterion in a distributed system where any number of nodes may crash.