IOA: Distributed Algorithms  Distributed Programs

1. I A O IOA: Distributed Algorithms  Distributed Programs Nancy Lynch PODC 2000 Collaborators: Steve Garland, Josh Tauber, Anna Chefter, Antonio Ramirez, Michael Tsai, Mandana Vaziri, Tina Nolte

2. What we want to do: See how abstract I/O automatonmodels of distributed algorithms and services could be used in producing and maintaining actual distributed programs.

3. Why use models in programming? • Models let you: • Build complex things and get them right • Change things and understand the consequences • Explain clearly how things work • Other engineering disciplines use them

4. But why I/O automaton models? • Simple mathematical basis for describing structure + behavior of systems of interacting components • Already used for: • Distributed algorithms, impossibility results • System case studies: • Group communication services (Orca, Transis, Ensemble,…) • Communication protocols (TCP, T/TCP,…) • Hybrid (continuous/discrete) systems (TCAS,…)

5. I/O automata[Lynch, Tuttle 87] • Nondeterministic state machines • Infinite state • Input/output/internal actions • Transitions, executions, traces • Supports modularity: • Composition • Levels of abstraction • Mathematical model, language-independent

6. How I/O automata are used • Model service specs, distributed algorithms • Refine, from high level global service spec to detailed distributed algorithm: • Make models as nondeterministic as possible • Prove correctness, using invariants, simulation relations, composition

7. TO TO Broadcast Service Spec [Fekete, Lynch, Shvartsman, PODC 97] Signature: input: broadcast(a,p) output: receive(a,p,q) internal: order(a,p) State: queue, sequence of (a,p), initially empty for each p: pending[p], sequence of a, initially empty next[p], positive integer, initially 1

8. Transitions: broadcast(a,p) Effect: append a to pending[p] order(a,p) Precondition: a is head of pending[p] Effect: remove head of pending[p]; append (a,p) to queue receive(a,p,q) Precondition: queue[next[q]] = (a,p) Effect: next[q] := next[q] + 1 TO Broadcast

9. I A O For proofs For simulation, code generation IOA Language[Garland, Lynch 97] • Programming/specification language for defining I/O automata • Similar to pseudocode • Explicitly describes: • Signature, structured state, precondition/effects • Nondeterministic choice, composition, invariants, levels of abstraction • Declarative + imperative

10. IOA Tools • Front end: Parser, static checker, intermediate Java representation [Garland, Ramirez] • Support for: • Composing models [Chefter 98] [Garland, Lynch] • Refining models, from global specification to low-level distributed algorithm model: Step correspondence [Ramirez 00]

11. IOA Tools • Prototype code generator, for generating distributed code from low-level distributed algorithm models [Tauber, Tsai] • Validation tools: • Simulator [Chefter 98] [Ramirez 00] Paired simulation: • Theorem-prover interfaces: PVS [Devillers], Isabelle? LP? NuPRL? [Nolte] • Automatic?

12. Modeling Projects • Distributed spanning tree algorithms [Luhrs, Nolte] • Distributed replicated data management algorithms: Lamport state machines; Attiya, Bar-Noy, Dolev, … [Dean, Karlovich, Rosen] • Future: • Practical communication protocols, services • Interacting Java objects

13. TLA and IOA • TLA and IOA both: • Use precondition/effect style • Support nondeterministic choice • Support similar kinds of assertional proofs • TLA: • Is typeless • Is declarative • Has good automatic tools • IOA: • Uses Larch Shared Language data types • Declarative + imperative • Emphasizes system decomposition

14. I A O IOA Code Generator (Making IOA Run) Joshua A. Tauber PODC Rump Session July 17, 2000 Joint work with: Steve Garland, Nancy Lynch, Michael Tsai

15. What • Generate standard language (Java) translation of IOA program that will run in a physically distributed network • Execution should be efficient • No global synchronization

16. Why • (Short term) Test bed for distributed algorithm design • (Long term) Find practical method for generating code from specifications

17. How • Make humans do hard thinking • Model and use existing external services (e.g. network, console) • Use library of hand-written data type implementations • Stay in IOA until very last step • Successive refinement • Supports application of other tools

18. Env System Node-Channel Form Global Specification Node-Channel Form

19. Abstract Channels • Abstract model for ease of programming (e.g., Reliable FIFO queue): • Algorithm that implements abstract channel in terms of (model of) real channel: Auxiliary Automaton Real channel

20. Environment Implementation Env Delay Buffer Console Parser

21. Generated vs. External Automata Env Code to Generate Algorithm Channel

22. Code Generation Process • Submit IOA program for node algorithm • Generate parser automaton • Compose algorithm, parser (computed), and auxiliary network automata (from library) • Resolve nondeterminism in schedule • Convert implicit ND to explicit ND • Resolve explicit ND (programmer help) • Emit target language code - Link to hand coded-datatype implementations

23. Truth in Advertising • Assume network implements model • Assumes data type implementations implement axiomatic definitions • No current fault tolerance • Still in progess • Composer • Code generator • Proof of design correctness