1. Dependent Types for Reasoning About Distributed Systems Paul Sivilotti - Ohio State Hongwei Xi - Cincinnati

2. Motivation and Context • Aim: practical support for the development of high-confidence distributed systems • practical: • modularity (components) • low cost • high-confidence: • respects resource budget, private memory… • executes “correctly” Dependent Types for Distributed Components

3. Gaining confidence that program text satisfies required behavior Specifying com-ponent behavior and reasoning about its com-position Component A Properties Program Text of A . . . System Properties Component B Properties Program Text of B . . . Component C Properties Program Text of C . . . Two Challenges Dependent Types for Distributed Components

4. 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 Dependent Types for Distributed Components

5. “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 ] Dependent Types for Distributed Components

6. 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 Dependent Types for Distributed Components

7. Client Program *[ non CS ! request ? token //holding is true CS: ninetyone(0); ! token //holding is false ] • To prove transient holding, show • CS terminates (ie ninetyone terminates) Dependent Types for Distributed Components

8. 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 • intarray(n) is the type for integer arrays of size n. Dependent Types for Distributed Components

9. McCarthy’s 91 Function {i:nat} /* metric: 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); } } Dependent Types for Distributed Components

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 Dependent Types for Distributed Components

11. 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 Dependent Types for Distributed Components

12. Feasibility of Project • Certificates • A tool (cidl) for testing transient in CORBA objects has been implemented • Transient, and other local certificates, have been applied to several examples • Dependent Types • A dependently typed language (Xanadu) has been formalized and prototyped • Xanadu applied to several examples Dependent Types for Distributed Components

13. Synergy of Collaboration • Paul: • Use transient properties to reason about progress in distributed systems • Use locally-checkable component properties to establish global system properties • Hongwei: • Design a dependent type system to capture termination properties • Implement a type-checker to verify captured termination properties Dependent Types for Distributed Components

14. Future Goals • Research topics • Certification of mobile code for distributed systems • Build high confidence systems • External Funding • NSF (OS/Compiler & SE/Language) • DARPA (high-confidence computing) Dependent Types for Distributed Components

15. Summary of Proposed Work • Extend dependent types to capture termination • Characterize certificates that can be supported by dependent types • Key qualities: • modular • holistic • high-confidence, not proof Dependent Types for Distributed Components