dependent types for high- confidence distributed systems paul sivilotti - ohio state hongwei xi –...

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


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


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


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


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


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); }}


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


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


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; }}


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


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


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


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 ]


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


Timestamped History

transient.P

true

false

P

timedanger dangerdanger

P

settimestamp

cleartimestamp

predicate evaluation…


Multiple Properties A component may have many

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


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

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

P

Q

R


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


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)


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

critical)

When is there “danger” of a possible violation?

P0

P1

P2

P3


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


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


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


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


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)


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)


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


DXanadu Integration: dependent types and

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

Implementation test bed


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


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


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


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.)

dependent types for high- confidence distributed systems paul sivilotti - ohio state hongwei xi –...

Documents

progress slide

expressions i j

return j

transient holding slide

false slide

int bitrev j

return bitrev j

p transient