IOA: Distributed Algorithms Distributed Programs

Post on 02-Jan-2016

43 views 5 download

description

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. What we want to do:. - PowerPoint PPT Presentation

Transcript of IOA: Distributed Algorithms Distributed Programs

1

IOA: Distributed Algorithms

Distributed Programs

Nancy LynchPODC 2000

Collaborators: Steve Garland, Josh Tauber,

Anna Chefter, Antonio Ramirez, Michael Tsai, Mandana Vaziri, Tina Nolte

IO A

2

What we want to do:

See how abstract I/O automaton models 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

• 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

How I/O automata are used

7

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

TO

8

TO BroadcastTransitions:

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

9

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

For proofs For simulation, code generation

IO A

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

IOA Code Generator (Making IOA Run)

Joshua A. TauberPODC Rump SessionJuly 17, 2000

Joint work with: Steve Garland, Nancy Lynch, Michael Tsai

IO A

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

Node-Channel Form

Env System

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:

Real channel

Auxiliary Automaton

20

Environment Implementation

Env

Console

Parser

DelayBuffer

21

Generated vs. External Automata

Env

Algorithm

Channel

Code to Generate

22

Code Generation Process

1. Submit IOA program for node algorithm

2. Generate parser automaton

3. Compose algorithm, parser (computed), and auxiliary network automata (from library)

4. Resolve nondeterminism in schedule– Convert implicit ND to explicit ND

– Resolve explicit ND (programmer help)

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