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

3. Dependent Types for Distributed Components2 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”

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

5. Dependent Types for Distributed Components4 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

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

7. Dependent Types for Distributed Components6 E.g.: Mutual Exclusion System: every client request is eventually satisfied Token-passing Layer Client C Client D Client E Client B Client A Client: token is eventually returned transient holding

8. Dependent Types for Distributed Components7 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 ]

9. Dependent Types for Distributed Components8 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.

10. Dependent Types for Distributed Components9 McCarthy’s 91 Function {i:nat} /* metric: max(0, 101-i) */ [j:int | (i 100  j = i-10)] int(j) ninetyone (x:int(i)) { if (x <= 100) { return ninetyone (ninetyone (x+11)); } else { return (x-10); }

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

12. Dependent Types for Distributed Components11 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

13. Dependent Types for Distributed Components12 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

14. Dependent Types for Distributed Components13 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

15. Dependent Types for Distributed Components14 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)

16. Dependent Types for Distributed Components15 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