1 / 37

Enhancing Confidence in Distributed Systems Through Dependent Types

This paper explores the application of dependent types in high-confidence distributed systems, focusing on specifying component behaviors and reasoning about their composition. It addresses the challenges of validating program correctness by introducing systematically quantified progress properties using enriched types. The work presents a dual-phase approach encompassing foundational principles of dependent types for metrics, followed by integration into a distributed dependently typed language, DXanadu. This innovative methodology aims to provide programmers with effective tools for certification and testing of program termination and progress.

tate-quinn
Télécharger la présentation

Enhancing Confidence in Distributed Systems Through Dependent Types

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dependent Types for High-Confidence Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.)

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

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

  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 Specifying and Testing Quantified Progress Properties

  5. Phase I Dependent Types for Metrics

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

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

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

  13. Phase I Functional Certificates

  14. “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

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

  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. P true false time predicate evaluation… danger danger danger P settimestamp cleartimestamp Timestamped History transient.P Specifying and Testing Quantified Progress Properties

  19. Multiple Properties • A component may have many progress properties transient.(status = critical) transient.(status = idle ^ button_down) transient.( . . . ) Specifying and Testing Quantified Progress Properties

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

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

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

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

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

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

  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 Specifying and Testing Quantified Progress Properties

  31. Phase II DXanadu: A distributed dependently-typed language

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

  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) Specifying and Testing Quantified Progress Properties

  37. Dependent Types for High-Confidence Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi – Cincinnati (Boston Univ.)

More Related