Checking Consistency Properties: Tractable Reductions to - - PowerPoint PPT Presentation

Checking Consistency Properties: Tractable Reductions to Reachability

Constantin Enea

IRIF , University Paris Diderot

Concurrent/Distributed Objects

• Modern computer software is increasingly concurrent
• performance improvements often achieved by parallelizing
• perations
• concurrent/distributed objects encapsulate concurrent

shared-memory accesses into higher-level abstract data types

• java.util.concurrent, Intel Thread Building Blocks
• Amazon SS3, MongoDB
• the widespread usage of these libraries demands for precise

(formal) specifications 


Consistency Criteria

• Define an abstraction of the library behaviors
• Example: linearizability ensures an atomic view of the

method calls

Thread 1 Thread 2

enq(1) enq(2)

deq ⇒ 1 deq ⇒ 2

Thread 1 Thread 2

enq(1) enq(2)

deq ⇒ 1 deq ⇒ 2

“abstracted to”

Modeling Library Behaviors: Histories

pop ⇒ 1 push(2) push(3) push(1) pop ⇒ 2

happens-before partial order

push(1) pop ⇒ 1 push(2) push(3) pop ⇒ 3 pop ⇒ 2

Thread 1 Thread 2

pop ⇒ 3 push(1) pop ⇒ 1 push(2) push(3) pop ⇒ 3 pop ⇒ 2

program order

Consistency Criteria

• Expressible as (existential) second order formulas over histories
• Linearizability:

(Invoc, Hb) is linearizable iff (Invoc, Hb) | = ∃Lin. Hb ⊆ Lin ∧ Spec(Lin)

push(1) pop ⇒ 1 push(2) push(3) pop ⇒ 3 pop ⇒ 2

push(1) pop⇒1 push(2) pop⇒2 pop⇒3 push(3)

linearized to

Consistency Criteria

• Expressible as second order formulas over histories
• Linearizability:
• Sequential Consistency:
• Causal Consistency: …

(Invoc, Hb) is linearizable iff (Invoc, Hb) | = ∃Lin. Hb ⊆ Lin ∧ Spec(Lin) (Invoc, Po) is sequentially consistent iff (Invoc, Po) | = ∃Lin. Po ⊆ Lin ∧ Spec(Lin)

Verifying Consistency Criteria

Challenges:

• Checking consistency of a single history is often NP-complete
• results in descriptive complexity => no first-order formulation
• Checking consistency of finite-state implementations is often undecidable
• Example: linearizability, sequential/causal consistency

Goal:

• Identifying classes of implementations/specifications for which checking

consistency is reducible to reachability (assertion checking)

• Polynomial procedures for checking consistency of single histories

Results

Criterion Implementations Specifications Eventual Consistency All Describable using "multiset automata” Causal Consistency Data Independent Key-value stores Linearizability Data Independent Register, Stack, Queue, Priority Queue

BEH, POPL’14 BEGH, POPL’17 BEEH, ICALP’15 BEW, CONCUR’17

Geo-Replicated Data Structures

• Strong (sequential) consistency

write(x,1) write(x,2)

Geo-Replicated Data Structures

• Strong (sequential) consistency

write(x,1) write(x,2) read(x) ⇒ 1 read(x) ⇒ 2 read(x) ⇒ 1 read(x) ⇒ 2

Geo-Replicated Data Structures

• Strong (sequential) consistency is impossible while being

available and tolerating network partitions: the CAP theorem

write(x,1) write(x,2) read(x) ⇒ 1 read(x) ⇒ 2 read(x) ⇒ 1 read(x) ⇒ 2

Geo-Replicated Data Structures

• Tolerating faults while preserving availability leads to

anomalies w.r.t. strong (sequential) consistency

write(x,1) write(x,2) read(x) ⇒ 1 read(x) ⇒ 2 read(x) ⇒ 2 read(x) ⇒ 1

Updates are seen in different orders

Verifying Causal Consistency

• The set of allowed anomalies are defined by weak consistency criteria,

e.g., eventual consistency, causal consistency.

• Goal: Algorithmic methods for checking causal consistency.
• Verifying a single history is NP-Complete
• Verifying a finite-state implementation is undecidable (finite nb. of sites)
• Linearizability. EXPSPACE-complete

Sequential Consistency. Undecidable Causal Consistency. Undecidable Eventual Consistency. Decidable

What About Key-Value Stores ?

• Checking causal consistency remains undecidable in general
• Restricting to data independent implementations
• behaviors don’t depend on the stored/input values
• For data independent implementations, it is enough to check executions

where each value is written at most once

What About Key-Value Stores ?

• Bad pattern = a set of operations related in a particular way
• Approach: identify a set of bad patterns X such that

A history is causally-consistent iff it contains a bad pattern from X

• Consequences:
• checking causal consistency for a single history is polynomial time
• checking causal consistency is reducible to assertion checking
• define a monitor that tracks the presence of bad patterns

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Causal Consistency

Definition of Causal Consistency

write(x, 1) write(x, 2) read(x) I 1 read(x) I 2 read(x) I 2 read(x) I 1

program order

There exists a causality order CO such that the causal past of every read can explain its value CO includes the program (site) order

10 / 35

Definition of Causal Consistency

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Causal Consistency

Definition of Causal Consistency

write(x, 1) write(x, 2) read(x) I 1 read(x) I 2 read(x) I 2 read(x) I 1

program order

write(x, 1) write(x, 2) write(x, 1) write(x, 2) read(x) I 2 read(x) I 1 There exists a causality order CO such that the causal past of every read can explain its value CO includes the program (site) order

10 / 35

Definition of Causal Consistency

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Causal Consistency

Causal Consistency Violations

Causally related writes must be seen by all sites in the same order. write(x, 1) read(x) I 1 write(x, 2) write(y, 3)

11 / 35

Causal Consistency Violations

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Causal Consistency

Causal Consistency Violations

Causally related writes must be seen by all sites in the same order. write(x, 1) read(x) I 1 write(x, 2) write(y, 3) read(y) I 3 read(x) I 1

11 / 35

Causal Consistency Violations

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Causal Consistency

Formalizing Causal Consistency

Specification = a set of sequences of operations write(x, 1) · write(y, 2) · read(x) I 1 · read(y) I 2

12 / 35

Formalizing Causal Consistency

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Causal Consistency

Formalizing Causal Consistency

Specification = a set of sequences of operations write(x, 1) · write(y, 2) · read(x) I 1 · read(y) I 2 A history h = (O, PO) is causally consistent w.r.t. a specification S iff there exists a strict partial order CO s.t. AxCausal : PO ✓ CO AxCausalValue : 8o 2 O. CausalPast(CO, o) v S

(CausalPast(CO, o) = the restriction of CO to CO−1(o) [ {o}

• CO

CausalPast(CO, o)

v means “can be linearized to”)

12 / 35

Formalizing Causal Consistency

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Data Independent Implementations Bad Patterns

Data Independent Implementations

Observation: Written values do not influence behaviors. ⇒ We can assume written values are unique. write(x, 1) write(x, 2) write(x, 3) write(x, 4) read(x) I 3 Unicity of writes implies a canonical causality relation (included in every other causality relation).

18 / 35

Differentiated histories

A history is differentiated if each value is written at most once

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Data Independent Implementations Bad Patterns

Bad Patterns to Characterize Violations

Bad pattern: set of operations related is a particular way Defined using the following orders: PO (program order): connects operations from the same site RF (reads-from relation): connects write to read CO (causal order): defined as (PO ∪ RF)+

19 / 35

Bad Patterns

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Data Independent Implementations Bad Patterns

Bad Pattern for Causal Consistency: WriteCORead

Two writes w1 and w2, and one read r1 on the same variable:

r1 reads-from w1 w1 <CO w2 <CO r1

Example: write(x, 1) write(y, 2) read(y) I 2 write(x, 2) read(x) I 2 read(x) I 1

20 / 35

Example: WriteCORead

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Data Independent Implementations Bad Patterns

Bad Patterns for Causal Consistency

WriteCORead: two writes w1 and w2, and one read r1 on some x s.t.

r1 reads-from w1 w1 <CO w2 <CO r1

CyclicCO: CO = (PO [ RF)+ is cyclic ThinAir: a read operation r = read(x) I v with v 6= 0 s.t.

w 6<RF r for every write w

WriteCOInit: a read operation r = read(x) I 0 s.t.

w <CO r for some write w on x

22 / 35

Bad Patterns for CC

We considered other variations: causal convergence (global arbitration) and causal memory (process-local arbitration)

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Application to Single-Trace Verification Application to All-Traces Verification

Recognizing Bad Patterns with Register Automata

By data independence, we can use a bounded number of values Registers are needed to store variable names while tracking causality paths WriteCORead:

q1 CausalPath [d 7! 3] CausalPath [d 7! 4] qerr p, wr(x, 1) wit := x var := x site := p p, wr(x, 2) wit == x var := x site == p p, rd(x) I 1 wit == x site == p

25 / 35

Recognizing Bad Patterns

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Application to Single-Trace Verification Application to All-Traces Verification

Recognizing Bad Patterns with Register Automata

By data independence, we can use a bounded number of values Registers are needed to store variable names while tracking causality paths WriteCORead:

q1 CausalPath [d 7! 3] CausalPath [d 7! 4] qerr p, wr(x, 1) wit := x var := x site := p p, wr(x, 2) wit == x var := x site == p p, rd(x) I 1 wit == x site == p

CausalPath tracks alternations

• f PO and RF

qb qa p, rd(x) I d site := p var == x p, wr(x, d) var := x site == p

CausalPath

25 / 35

Recognizing Bad Patterns

Definitions of Causal Consistency Characterization of Causal Consistency using Bad Patterns Using Bad Patterns for Verification Application to Single-Trace Verification Application to All-Traces Verification

Recognizing Bad Patterns with Register Automata

By data independence, we can use a bounded number of values Registers are needed to store variable names while tracking causality paths WriteCORead:

q1 CausalPath [d 7! 3] CausalPath [d 7! 4] qerr p, wr(x, 1) wit := x var := x site := p . . . 5 . . . 5 . . . 5 p, wr(x, 2) wit == x var := x site == p p, rd(x) I 1 wit == x site == p

CausalPath tracks alternations

• f PO and RF

qb qa p, rd(x) I d site := p var == x p, wr(x, d) var := x site == p

CausalPath

. . . 5 . . . 5

25 / 35

Recognizing Bad Patterns

Conclusions

• effective reductions from checking consistency criteria to

reachability (assertion checking)

• establishing theoretical limits
• re-use the existing verification technology
• Open questions:
• can these results be explained in a unifying theory ?
• other consistency criteria or specifications (sets, CRDTs)
• consistency criteria for transactional systems