370 likes | 467 Views
Dependent Types for High-Confidence Distributed Systems. Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.). Gaining confidence that program text satisfies required behavior. Specifying com-ponent behavior and reasoning about its com-position. Component A Properties.
E N D
Dependent Types for High-Confidence Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.)
Gaining confidence that program text satisfies required behavior Specifying com-ponent behavior and reasoning about its com-position Component A Properties Component A Program Text System Properties Component B Properties Component B Program Text Component C Properties Component C Program Text Two Challenges Specifying and Testing Quantified Progress Properties
Certificates temporal logic local properties Two Synergistic Solutions • Dependent Types • enriched types • familiar, low cost • Typically not tied to real programs • Typically not used for reasoning about progress • Synergy: locality • Surprising Connection: termination Specifying and Testing Quantified Progress Properties
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 Specifying and Testing Quantified Progress Properties
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 Specifying and Testing Quantified Progress Properties
Metrics and Integer Constraints • Index variables and expressions • i+j, i-j, i*j, i/j, … • Let m = <i1,...,in> be a tuple of index expressions. We write f|- m: metric if we have f |- ij:nat for 1 j n • Lexicographic ordering • Well-founded Specifying and Testing Quantified Progress Properties
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
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
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
Bit Reversing from FFT {a:nat,b:pos}<max(0, a-b)> => int bitrev (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
Bit Reversing from FFT {a:nat,b:pos}<max(0, a-b)> => int bitrev (j:int(a),k:int(b)) { if (k < j) { assert (k > 1); return bitrev (j-k,k/2); } else { return j+k; } } Specifying and Testing Quantified Progress Properties
Phase I Functional Certificates
“Transient”: A Certificate for Progress • 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 ] Specifying and Testing Quantified Progress Properties
System: every client request is eventually satisfied Client: token is eventually returned transient holding Token-passing Layer E.g.: Mutual Exclusion Client C Client D Client B Client A Client E Specifying and Testing Quantified Progress Properties
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
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
P true false time predicate evaluation… danger danger danger P settimestamp cleartimestamp Timestamped History transient.P Specifying and Testing Quantified Progress Properties
Multiple Properties • A component may have many progress properties transient.(status = critical) transient.(status = idle ^ button_down) transient.( . . . ) Specifying and Testing Quantified Progress Properties
P Multiple Transient Prop’s transient.P ^ transient.Q ^ transient.R • Complexity: • Space: n timestamps kept • Time: n predicate evaluations with each step Q R Specifying and Testing Quantified Progress Properties
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
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 variable For 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
Functional Transience Ak :: transient.(metric = k ^ status = critical) • When is there “danger” of a possible violation? P3 P2 P1 P0 Specifying and Testing Quantified Progress Properties
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
Functional Transience Ak :: transient.(metric = k ^ status = critical) • Complexity: • Space: 1 timestamp & value(s) of dummy(s) • Time: 1 function & 1 predicate evaluation P3 P2 P1 P0 TS S R R R R C S Specifying and Testing Quantified Progress Properties
Generalization: Relational Transience • Number of predicates that can be simultaneously true is bounded (B) Ak :: transient.(k <= metric <= k+1 ^ critical) P3 P2 P1 P0 2 1 0 Specifying and Testing Quantified Progress Properties
Monitoring Relational Transience • Complexity • Space: B timestamps & dummy values • Time: 1 relation eval’n & 2B timestamp updates P3 P2 P1 P0 TS1 S R R C S C TS0 S S R R C Specifying and Testing Quantified Progress Properties
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
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
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 Specifying and Testing Quantified Progress Properties
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 Specifying and Testing Quantified Progress Properties
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
POBox C DXanadu #4 POBox A POBox B DXanadu #0 DXanadu #3 DXanadu #1 DXanadu #2 Architecture • Java RMI for communication backbone • Serialization of message types • Static bootstrapping and component binding PostCentral java ocaml Specifying and Testing Quantified Progress Properties
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
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) Specifying and Testing Quantified Progress Properties
Dependent Types for High-Confidence Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.)