Ports, Protocols, and Processes: a Programming Paradigm? Peter - - PowerPoint PPT Presentation

▶
ports protocols and processes
SMART_READER_LITE
LIVE PREVIEW

Ports, Protocols, and Processes: a Programming Paradigm? Peter - - PowerPoint PPT Presentation

Apr 21, 2023 7 likes •668 views

Ports, Protocols, and Processes: a Programming Paradigm? Peter Grogono Computer Science and Software Engineering Concordia University 22 November 2007 1/50 The Erasmus Project Desiderius Erasmus of Rotterdam (1466-1536) 2/50 Dramatis

slide-1
SLIDE 1

Ports, Protocols, and Processes:

a Programming Paradigm? Peter Grogono

Computer Science and Software Engineering Concordia University 22 November 2007

1/50

slide-2
SLIDE 2

The Erasmus Project

Desiderius Erasmus of Rotterdam (1466-1536)

2/50

slide-3
SLIDE 3

Dramatis Person

Brian Shearing Peter Grogono

Rana Issa Nima Jafroodi Nurudeen Lameed

3/50

slide-4
SLIDE 4

Inspiring Thoughts

``The fox has many tricks. The hedgehog has but one. But that is the best of all.'' Erasmus, c. 1500 ``It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.'' Perlis, 1982 ``One thing [language designers] should not do is to include untried ideas of their own. Their task is consolidation, not innovation.'' Hoare, 1974

4/50

slide-5
SLIDE 5

Road Map

Programming

what we've done

Principles

why we've done it

Reasoning

how we know it works

Development

how we fit it together

For and against

why we bother

5/50

slide-6
SLIDE 6

Main

Cell

Main = (); Main();

6/50

slide-7
SLIDE 7

Main

Cell

prot = [ ]; Main = (); Main();

6a/50

slide-8
SLIDE 8

serverProc

Process

clientCell Main prot prot = [ ]; serverProc = { p +: prot | }; clientCell = ( p -: prot | ); Main = ( p :: prot; serverProc(p); clientCell(p) ); Main();

6b/50

slide-9
SLIDE 9

prot = [ start; *( query: Text; ^reply: Integer ); stop ]; serverProc = { p +: prot | p.start; loopselect || input: Text := p.query; p.reply := 0 || p.stop; exit end }; clientCell = ( p -: prot | ); Main = ( p :: prot; serverProc(p); clientCell(p) ); Main();

7/50

slide-10
SLIDE 10

serverProc clientCell clientProcess Main prot clientProc = { p -: prot | }; clientCell = ( p -: prot | clientProc(p) );

8/50

slide-11
SLIDE 11

Protocols

query = [ question; ^answer ] sequence = [ first: Integer; second: Text; third: Float ] method1 = [ *( arg1; arg2; ...; ^result ) ] method2 = [ *( arg1; arg2; ...; ^res1; ^res2 ) ] class = [ *( M1 | M2 | ... | Mn ) ]

9/50

slide-12
SLIDE 12

Statements

select || p.red; ... || p.yellow; ... || p.green; ... end select |stored < 10| buff[i] := p.x; ... |stored > 0| q.y := buff[j]; ... end select fair ... select ordered ... select random ...

10/50

slide-13
SLIDE 13

Processes

prot = [ *( arg: Integer ) ]; filter = { p +: prot | prime: Integer := p.arg; sys.out := text prime + ’ ’; q -: prot; filter(q); loop n: Integer := p.arg; if n % prime != 0 then q.arg := n end end };

11/50

slide-14
SLIDE 14

filter p q filter p q filter p q filter p q filter p q filter p q filter pq filter pq filter p q filter p q filter p q filter p q

12/50

slide-15
SLIDE 15

filter

12a/50

slide-16
SLIDE 16

Semantics vs. Deployment

square squareCell client clientCell main p p ch

13/50

slide-17
SLIDE 17

Code

sqProt = [ *( query: Float; ^reply: Text ) ]; square = { p +: sqProt | loop q: Float := p.query; p.reply := text(q * q); end }; squareCell = ( port +: sqProt | square(port) ); client = { p -: sqProt | p.query := 2; sys.out := p.reply + "\n"; }; clientCell = ( port -: sqProt | client(port) ); main = ( ch :: sqProt; squareCell(ch); clientCell(ch) ); main();

14/50

slide-18
SLIDE 18

Metacode

<Mapping> <Processor> alpha.encs.concordia.ca <Port> 5555 </Port> <Cell> squareCell </Cell> <Cell> clientCell1 </Cell> </Processor> <Processor> beta.encs.concordia.ca <Port> 5555 </Port> <Cell> squareCell1 </Cell> <Cell> clientCell </Cell> </Processor> </Mapping>

15/50

slide-19
SLIDE 19

Road Map

Programming

what we've done

Principles

why we've done it

Reasoning

how we know it works

Development

how we fit it together

For and against

why we bother

16/50

slide-20
SLIDE 20

Cells

Programs consist of cells Cells may contain variables, processes, and cells Cells can be of any size

programs are ``fractal''

Cells are ``first-class citizens'' Control flow never crosses a cell boundary Cells are explicitly provided with all needed resources Cells may exchange messages Processes within a cell behave as co-routines

17/50

slide-21
SLIDE 21

18/50

slide-22
SLIDE 22

Processes

A process is always inside a cell Processes may contain variables, processes, and cells Processes are ``first-class citizens'' All actions are performed within processes Control flow never crosses a process boundary A process may access variables within its cell Processes communicate by exchanging messages A process relinquishes control when it communicates

no race conditions

19/50

slide-23
SLIDE 23

C1 # C2 # P1 P2 P3 V1 V2

One program counter per cell

20/50

slide-24
SLIDE 24

Shared Variables

proc = { p +: prot; sv: Float | ... sv ... sys.out := sv; p.val := ... sys.out := sv; }

21/50

slide-25
SLIDE 25

Shared Variables

proc = { p +: prot; sv: Float | ... sv ... sys.out := sv; p.val := sv; sys.out := sv; }

21a/50

slide-26
SLIDE 26

Shared Variables

proc = { ... | atomic { ...

  • pen

{ p.val := ... } ... } }

21b/50

slide-27
SLIDE 27

Protocols

Protocols define interfaces Protocols specify communication patterns Protocols consist of typed messages and signals Protocols define sequence, choice, and repetition There is a ``satisfaction'' relation on protocols

details later

22/50

slide-28
SLIDE 28

Messages

A ``sent'' message is an lvalue: p.result := 42; A ``received'' message is an rvalue: sum := p.val + ...; Signals synchronize: p.stop

23/50

slide-29
SLIDE 29

Messages

A ``sent'' message is an lvalue: p.result := 42; A ``received'' message is an rvalue: sum := p.val + q.val; Signals synchronize: p.stop

23a/50

slide-30
SLIDE 30

Separation of Concern

Cells define structure ∼ Processes define action Code defines meanings ∼ Metacode defines deployment Protocols specify processes ∼ Protocols ensure satisfaction

24/50

slide-31
SLIDE 31

Road Map

Programming

what we've done

Principles

why we've done it

Reasoning

how we know it works

Development

how we fit it together

For and against

why we bother

25/50

slide-32
SLIDE 32

26/50

slide-33
SLIDE 33

Labelled Transition System (LTS): Q = { q0, q1, q2, q3 } , L = { α } , T = { (q0, α, q0), (q1, α, q2), (q2, α, q3) } .

q0 q1 q2 q3 α α α

27/50

slide-34
SLIDE 34

Strong Simulation: S ⊆ Q × Q If (p, q) ∈ S and p

α

− → p′ then there exists q′ ∈ Q such that (p′, q′) ∈ S and q

α

− → q′.

p′ q′ q p S α S α

28/50

slide-35
SLIDE 35

q0 q1 q2 q3 α α α

S = { (q1, q0), (q2, q0), (q3, q0) } is a strong simulation.

29/50

slide-36
SLIDE 36

If · (Q, L, T) is a LTS · A ⊆ Q · B ⊆ Q · S ⊆ A × B is a strong simulation then

      

A ⊑ B (A is simulated by B) B ⊒ A (B simulates A) ⊒ is reflexive, transitive, computable.

30/50

slide-37
SLIDE 37

Protocol P : α; ( β | γ ); δ LTS L(P ):

A B C D α β γ δ

31/50

slide-38
SLIDE 38

Code C:

p.alpha; select || p.beta; ... || p.gamma; ... end; p.delta

LTS L(C):

A B C D α β γ δ

32/50

slide-39
SLIDE 39

Server Client S PS PC C

L(S) ⊒ L(Ps) ⊒ L(Pc) ⊒ L(C)

33/50

slide-40
SLIDE 40

q0 q1 q2 q3 α α α

Server:

loop p.alpha := ... end

Protocol:

[ *( alpha ) ]

Client:

x := p.alpha; y := p.alpha

34/50

slide-41
SLIDE 41

Hennessy-Milner Logic

Syntax: F = X (states satisfying X) | tt (all states) | ff (no states) | F1 ∧ F2 (intersection) | F1 ∨ F2 (union) | αF (some α-trans − → F ) | [α]F (all α-trans − → F )

35/50

slide-42
SLIDE 42

Semantics (with respect to an LTS (Q, L, T)): [ [·] ] : Σ → P(Q) → P(Q) [ [ X ] ](S) = S [ [ tt ] ](S) = Q [ [ ff ] ](S) = ∅ [ [ F1 ∧ F2 ] ](S) = [ [ F1 ] ](S) ∩ [ [ F2 ] ](S) [ [ F1 ∨ F2 ] ](S) = [ [ F1 ] ](S) ∪ [ [ F2 ] ](S) [ [ α ] ](S) = { p | ∃p′ ∈ S . p

α

− → p′ } [ [ [α] ] ](S) = { p | ∀p′ . p

α

− → p′ ⇒ p′ ∈ S }

36/50

slide-43
SLIDE 43

Reasoning - Summary

Code Procotols

      

− → LTS − →

      

⊒ (simulates) HM Logic Also: FSP / LTSA (Magee & Kramer)

Finite State Processes / Labelled Transition System Analyzer

TLA+ (Lamport)

Temporal Logic of Actions Plus

37/50

slide-44
SLIDE 44

Road Map

Programming

what we've done

Principles

why we've done it

Reasoning

how we know it works

Development

how we fit it together

For and against

why we bother

38/50

slide-45
SLIDE 45

39/50

slide-46
SLIDE 46

Requirements Specification Design PL machine code

40/50

slide-47
SLIDE 47

Change moves upwards in the funnel: spaghetti

??

− → waterfall structured code − → SADT

Structured Analysis & Design Technique

  • bject-oriented languages −

→ OOAD

Object-Oriented Analysis & Design

aspect-oriented languages − → AOSD

Aspect-Oriented Software Development

process-oriented languages

??

− → POMDD

Process-Oriented Model-Driven Design

41/50

slide-48
SLIDE 48

Therefore: To effect change in the software development process, we must change the programming paradigm.

42/50

slide-49
SLIDE 49

Hypothesis

POMDD will succeed because: real world ∼ = concurrent processes concurrent processes ⇒ multiprocessors multiprocessors ⇒ concurrent software concurrent software ⇒ models real world cells/processes ⇒ lower coupling lower coupling ⇒ refactoring

43/50

slide-50
SLIDE 50

Road Map

Programming

what we've done

Principles

why we've done it

Reasoning

how we know it works

Development

how we fit it together

For and against

why we bother

44/50

slide-51
SLIDE 51

The case against

45/50

slide-52
SLIDE 52

The case against

Programming languages are not the problem

45a/50

slide-53
SLIDE 53

The case against

Programming languages are not the problem Object-oriented programming is good enough

45b/50

slide-54
SLIDE 54

The case against

Programming languages are not the problem Aspect-oriented programming is good enough

45c/50

slide-55
SLIDE 55

The case against

Programming languages are not the problem Aspect-oriented programming is good enough We've hidden the hard bits

CICS, J2EE, CORBA, ...

45d/50

slide-56
SLIDE 56

The case against

Programming languages are not the problem Aspect-oriented programming is good enough We've hidden the hard bits

CICS, J2EE, CORBA, ...

Introducing a new paradigm is no longer feasible

45e/50

slide-57
SLIDE 57

The case for

46/50

slide-58
SLIDE 58

The case for

Many distributed applications

46a/50

slide-59
SLIDE 59

The case for

Many distributed applications Multicore processors

46b/50

slide-60
SLIDE 60

The case for

Many distributed applications Multicore processors Process-oriented programming is ... good

46c/50

slide-61
SLIDE 61

The case for

Many distributed applications Multicore processors Process-oriented programming is ... good We need software

                                            

development maintenance growth adaptation evolution refactoring

46d/50

slide-62
SLIDE 62

Competition

ABCL/1 Joyce Ada Mozart/Oz Cilk Occam-π Concurrent Pascal SALSA Erlang SR

47/50

slide-63
SLIDE 63

Wrap Up

Objects ... Aspects ... Threads ... Locks ... × Hidden guru code ... × Modular concurrency ... √

48/50

slide-64
SLIDE 64

Erasmus provides ...

safe concurrency modularity scalability modelling capability weak coupling testing

49/50

slide-65
SLIDE 65

Erasmus provides ...

safe concurrency modularity scalability modelling capability weak coupling testing

... we hope!

49a/50

slide-66
SLIDE 66

The End

50/50