Brief Announcement: Semantics of Eventually Consistent Replicated Sets

Abstract

This paper studies the semantics of sets under eventual consistency. The set is a pervasive data type, used either directly or as a component of more complex data types, such as maps or graphs. Eventual consistency of replicated data supports concurrent updates, reduces latency and improves fault tolerance, but forgoes strong consistency (e.g., linearisability). Accordingly, several cloud computing platforms implement eventually-consistent replicated sets [2,4].The sequential semantics of a set are well known, and are defined by individual updates, e.g., {true}add(e){e ∈ S} (in "{pre-condition} computation {post-condition}" notation), where S denotes its abstract state. However, the semantics of concurrent modifications is left underspecified or implementationdriven.We propose the following Principle of Permutation Equivalence to express that concurrent behaviour conforms to the sequential specification: "If all sequential permutations of updates lead to equivalent states, then it should also hold that concurrent executions of the updates lead to equivalent states." It implies the following behavior, for some updates u and u :Specifically for replicated sets, the Principle of Permutation Equivalence requires that {e = f }add(e) remove(f ){e ∈ S ∧ f / ∈ S}, and similarly for operations on different elements or idempotent operations. Only the pair add(e) remove(e) is unspecified by the principle, since add(e); remove(e) differs from remove(e); add(e). Any of the following post-conditions ensures a deterministic result:{⊥e ∈ S} -Error mark {e ∈ S} -add wins {e / ∈ S} -remove wins {add(e) > CLK remove(e) ⇔ e ∈ S} -Last Writer Wins (LWW) where < CLK compares unique clocks associated with the operations. Note that

Composite Replicated Data Types

“…4 Things become more subtle if we allow removing elements, since we need to define the outcome of concurrent operations adding and removing the same element, as in the context N = (contains(42), {e, f }, aop, vis, ar), where aop(e) = add(42) and aop(f ) = remove(42). There are several possible ways of resolving this conflict [6]: in add-wins sets (AWset) adds always win against concurrent removes (so that the element ends up in the set), remove-wins sets (RWset) act vice versa, and last-writer-wins sets (LWWset) apply operations in the order of their timestamps. We specify the result of contains in these cases using the vis and ar orders in the operation context:…”

“…The semantics of the replicated store defined by (6) in §3 describes the store behaviour under any client and thus produces histories with all possible sets of client operations. However, a particular command C in the language of §2 generates only histories with certain sequences of operations.…”

“…An object variable declaration extends obj with a fresh object and F with the specification corresponding to its type. A client is interpreted by combining all histories its sessions produce in the session-local semantics with respect to obj and intersecting the result with (6). Note that we originally defined the store semantics (6) under the assumption that all replicated data types are primitive.…”

Making Operation-Based CRDTs Operation-Based

“…Commutative datatypes reflect a principle of permutation equivalence [11] stating that "If all sequential permutations of updates lead to equivalent states, then it should also hold that concurrent executions of the updates lead to equivalent states".…”

A Framework for Performance Evaluation of Decentralized Eventual Consistency Algorithms

“…Our framework supports both cases: CvRDT and CmRDT. The different algorithms implemented are published an detailed in [5,18,31]. In the following, we give a brief description of each algorithm integrated into the framework:…”