dependent types for high-confidence distributed systems

Dependent Types for High-Confidence Distributed

Systems

Paul Sivilotti - Ohio StateHongwei Xi – Cincinnati

(Boston Univ.)

Specifying and Testing Quantified Progress Properties 2

Gaining confidence that program text satisfies required behavior

Two Challenges Specifying com-

ponent behavior and reasoning about its com-position

SystemProperties

Component AProperties

Component BProperties

Component CProperties

Component AProgram Text

Component B Program Text

Component C Program Text

Specifying and Testing Quantified Progress Properties 3

Dependent Types enriched types familiar, low cost

Two Synergistic Solutions

Synergy: locality Surprising Connection: termination

Certificates temporal logic local properties

Typically not used for reasoning about progress

Typically not tied to real programs

Specifying and Testing Quantified Progress Properties 4

Talk Outline Background and Motivation Phase I: foundational

Dependent types for metrics local termination

Certificates for progress with metrics functional transient, functional next

Phase II: integration DXanadu: a distributed dependently

typed language

Phase I

Dependent Types for Metrics

Specifying and Testing Quantified Progress Properties 6

Dependent Types Dependent types are types that

can depend on the values of expressions

Examples int(i) is a singleton type that contains

the only integer equal to i int array(n) is the type for integer

arrays of size n

Specifying and Testing Quantified Progress Properties 7

Metrics and Integer Constraints Index variables and expressions

i+j, i-j, i*j, i/j, … Let = <i1,...,in> be a tuple of

index expressions. We write : metric if we have ij:nat for 1 j n Lexicographic ordering Well-founded

Specifying and Testing Quantified Progress Properties 8

McCarthy’s 91 Function

{i:nat} <max(0, 101-i)> =>[j:int | (i <= 100 j = 91) (i > 100 j = i-10)]

int(j)ninetyone (x:int(i)) { if (x <= 100) { return ninetyone (ninetyone (x+11)); } else { return (x-10); }}

Specifying and Testing Quantified Progress Properties 9

Cost Effectiveness In general, termination of a

program is difficult to prove However, critical sections tend to

be small and manageable More importantly, we provide the

programmer with a range of choices higher effort lower effort higher benefit lower benefit

Specifying and Testing Quantified Progress Properties 10

Spectrum of Choices Static Check

Programmer provides a metric Type-checker verifies monotonicity of metric

Dynamic Check Programmer provides a metric Type-checker inserts run-time tests to check

monotonicity of metric Checkpointing

Programmer does not provide a metric Checkpoint taken before “dangerous” action

Specifying and Testing Quantified Progress Properties 11

Bit Reversing from FFT

{a:nat,b:pos} <max(0, a-b)> => intbitrev (j:int(a),k:int(b)) { if (k < j) { return bitrev (j-k,k/2); } else { return j+k; }}

Specifying and Testing Quantified Progress Properties 12

Bit Reversing from FFT

{a:nat,b:pos} <max(0, a-b)> => intbitrev (j:int(a),k:int(b)) { if (k < j) { assert (k > 1); return bitrev (j-k,k/2); } else { return j+k; }}

Phase I

Functional Certificates

Specifying and Testing Quantified Progress Properties 14

Transient P for component C means: progress: if P ever becomes true, it

eventually becomes false locality: guaranteed by an action of C

alone More formally:

transient P a C : [ P wp.a.P ]

“Transient”: A Certificate for Progress

Specifying and Testing Quantified Progress Properties 15

E.g.: Mutual Exclusion

System: every client request is eventually satisfied

Token-passingLayer

Client CClient D

Client E

Client B

Client A

Client: token is eventually returned transient holding

Specifying and Testing Quantified Progress Properties 16

Client Program

To prove transient holding, show CS terminates (ie ninetyone terminates)

*[ non CS ! request ? token //holding is true CS: ninetyone(0); ! token //holding is false ]

Specifying and Testing Quantified Progress Properties 17

Testing Transience Recall for transient.P:

If P ever becomes true, it is later false Note: P may never become true

Consequence of formal definition:transient.P infinitely often P

To test for transience, use:transient.P finitely often P Look for a finite trace after which only

P

Specifying and Testing Quantified Progress Properties 18

Timestamped History

transient.P

true

false

P

timedanger dangerdanger

P

settimestamp

cleartimestamp

predicate evaluation…

Specifying and Testing Quantified Progress Properties 19

Multiple Properties A component may have many

progress propertiestransient.(status = critical)transient.(status = idle ^ button_down)transient.( . . . )

Specifying and Testing Quantified Progress Properties 20

Multiple Transient Prop’stransient.P ^ transient.Q ^ transient.R

Complexity: Space: n timestamps kept Time: n predicate evaluations with each step

P

Q

R

Specifying and Testing Quantified Progress Properties 21

Quantification of Transient Transient properties often quantified

“state changes eventually”Ak :: transient.(status = k)

“value of metric changes eventually”Ak :: transient.(metric = k ^ status = critical)

Naïve expansion is costly to monitor If dummy ranges over a set D of values:

|D| timestamps to maintain |D| predicate evaluations to perform

Specifying and Testing Quantified Progress Properties 22

Observation: Singularity Predicates are mutually exclusive Ak :: transient.(metric = k ^ status = critical) (P)

= transient.(metric = 0 ^ status = critical) (P0)

^ transient.(metric = 1 ^ status = critical) (P1) ^ transient.(metric = 2 ^ status = critical)… (P2)…

Truth of predicate functionally determines value of dummy variableFor P.(s,k) : predicate on state s, dummy k:

Ak :: transient.(P.(s,k)) is functional iffEf :: (P.(s,k) k = f.s)

Specifying and Testing Quantified Progress Properties 23

Functional TransienceAk :: transient.(metric = k ^ status =

critical)

When is there “danger” of a possible violation?

P0

P1

P2

P3

Specifying and Testing Quantified Progress Properties 24

Satisfying Functional Transience A functional transient property is

“satisfied” when either: The predicate that is true changes

Value(s) of dummy variable(s) that makes predicate true changes

All predicates become false Provide f: states dummy values

Evaluate k using f Evaluate P using k

Specifying and Testing Quantified Progress Properties 25

Functional TransienceAk :: transient.(metric = k ^ status =

critical)

Complexity: Space: 1 timestamp & value(s) of dummy(s) Time: 1 function & 1 predicate evaluation

P0

P1

P2

P3

TS S R R R CR S

Specifying and Testing Quantified Progress Properties 26

Generalization: Relational Transience Number of predicates that can be

simultaneously true is bounded (B)

Ak :: transient.(k <= metric <= k+1 ^ critical)

P0

P1

P2

P3

012

Specifying and Testing Quantified Progress Properties 27

Monitoring Relational Transience

Complexity Space: B timestamps & dummy values Time: 1 relation eval’n & 2B timestamp

updates

P0

P1

P2

P3

TS1

TS0

S

S

R R C

R R

S C

C S

Specifying and Testing Quantified Progress Properties 28

Ubiquity of Functional Transience Observation: Many quantifications

of transient appear to be functional E.g., timeouts and metrics

Method-response semantics “method M returns a value eventually”

Ak :: transient.(rcv_M = k+1 ^ snd_M = k)Ak :: transient.(rcv_M > k ^ snd_M = k)Ajk : j > k : transient.(rcv_M = j ^ snd_M = k)

Specifying and Testing Quantified Progress Properties 29

Other Progress Operators Transient is a very basic operator

Nice compositional properties Higher-order operator: leads-to (+-

>) Testing leads-to does not always

benefit from notion of functionality E.g., (Ak :: x = k +-> y = k)

Other simplifications can be made (Ak :: x = k +-> x < k)

Specifying and Testing Quantified Progress Properties 30

Quantification of Safety Properties Safety operator: P next Q

“if P holds, Q holds in the next state” Similar quantifications arise

Ak :: x = k next x <= k Also commonly functional

Truth of pre-predicate determines value(s) of dummy(s)

Similar performance benefit 1 function & 1 predicate evaluation

Phase II

DXanadu: A distributed dependently-typed language

Specifying and Testing Quantified Progress Properties 32

DXanadu Integration: dependent types and

distributed programming Metrics for termination and progress Certificates for specs and reasoning

Implementation test bed

Specifying and Testing Quantified Progress Properties 33

Communication Primitives Sequential Xanadu augmented with

send() and receive() keywords Point-to-point communication, with

fair merge at destination unit send(m,d)

m : basic type, arrays, non-nested records d : integer id of destination node

m = receive() Asynchronous send, blocking receive

Specifying and Testing Quantified Progress Properties 34

Architecture Java RMI for communication backbone

Serialization of message types Static bootstrapping and component binding

DXanadu #0

DXanadu #1

DXanadu #2

POBox A

DXanadu #3

POBox B

DXanadu #4

POBox C

PostCentral

java

ocaml

Specifying and Testing Quantified Progress Properties 35

Challenges to Be Faced Message typing

Dynamic structures (nesting, lists) Preserving (dependent) type information

Fault tolerance Conservative checkpointing for rollback

Linking code with certificate spec Run-time tests for validation

Dynamic computations Discovery, binding, departure

Experimentation with DXanadu

Specifying and Testing Quantified Progress Properties 36

Papers Acknowledging OBR LICS 01: “Dependent Types for Program

Termination Verification” FSE 01: “Increasing Client-Side Confidence in

Remote Component Implementations” ICFP 01: “A Dependently-Typed Assembly

Language” ICSE 01: “The Specification and Testing of

Quantified Progress Properties in Distributed Systems”

J. of Applied Systems Studies: “Testing the Protocol Conformance of Distributed components” (submitted)

Dependent Types for High-Confidence Distributed

Systems

Paul Sivilotti - Ohio StateHongwei Xi – Cincinnati

(Boston Univ.)