Ports, Protocols, andProcesses:

a Programming Paradigm?

Peter GrogonoComputer Science and Software Engineering

Concordia University

22 November 2007

1/50

The Erasmus Project

Desiderius Erasmus of Rotterdam (1466-1536)

2/50

Dramatis Person�

Brian Shearing

Peter Grogono

Rana Issa

Nima Jafroodi

Nurudeen Lameed

3/50

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 datastructure than 10 functions on 10 data structures.''

Perlis, 1982

``One thing [language designers] should not do is to includeuntried ideas of their own. Their task is consolidation,not innovation.''

Hoare, 1974

4/50

Road Map

Programmingwhat we've done

Principleswhy we've done it

Reasoninghow we know it works

Developmenthow we fit it together

For and againstwhy we bother

5/50

Main

Cell

Main = ();

Main();

6/50

Main

Cell

prot = [ ];

Main = ();

Main();

6a/50

serverProc

Process

clientCell

Main

prot

prot = [ ];

serverProc = { p +: prot | };

clientCell = ( p -: prot | );

Main = ( p :: prot; serverProc(p); clientCell(p) );

Main();

6b/50

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

serverProc

clientCell

clientProcess

Main

prot

clientProc = { p -: prot | };

clientCell = ( p -: prot | clientProc(p) );

8/50

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

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

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

filter

p q

filter

p q

filter

p q

filter

p q

filter

p q

filter

p q

filter

pq

filter

pqfilter

pqfilterpqfilterpqfilterpq

12/50

filter

12a/50

Semantics vs. Deployment

square

squareCell

client

clientCell

main

p pch

13/50

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

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

Road Map

Programmingwhat we've done

Principleswhy we've done it

Reasoninghow we know it works

Developmenthow we fit it together

For and againstwhy we bother

16/50

Cells

Programs consist of cells

Cells may contain variables, processes, and cells

Cells can be of any sizeprograms 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

18/50

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 communicatesno race conditions

19/50

C1

#

C2

#

P1

P2

P3V1 V2

One program counter per cell

20/50

Shared Variables

proc = { p +: prot; sv: Float |

... sv ...

sys.out := sv;

p.val := ...

sys.out := sv;

}

21/50

Shared Variables

proc = { p +: prot; sv: Float |

... sv ...

sys.out := sv;

p.val := sv;

sys.out := sv;

}

21a/50

Shared Variables

proc =

{ ... |

atomic

{

...

open

{

p.val := ...

}

...

}

}

21b/50

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 protocolsdetails later

22/50

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

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

Separation of Concern

Cells define structure ∼ Processes define action

Code defines meanings ∼ Metacode defines deployment

Protocols specify processes ∼ Protocols ensure satisfaction

24/50

Road Map

Programmingwhat we've done

Principleswhy we've done it

Reasoninghow we know it works

Developmenthow we fit it together

For and againstwhy we bother

25/50

26/50

Labelled Transition System (LTS):

Q = { q0, q1, q2, q3 } ,

L = {α } ,

T = { (q0, α, q0), (q1, α, q2), (q2, α, q3) } .

q0

q1 q2 q3

α

α α

27/50

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′

qp

S

α

S

α

28/50

q0

q1 q2 q3

α

α α

S = { (q1, q0), (q2, q0), (q3, q0) }

is a strong simulation.

29/50

If

· (Q, L, T ) is a LTS

· A ⊆ Q

· B ⊆ Q

· S ⊆ A × B is a strong simulation

then

A v B (A is simulated by B)

B w A (B simulates A)

w is reflexive, transitive, computable.

30/50

Protocol P :

α; ( β | γ ); δ

LTS L(P ):

A B C Dα

β

γ

δ

31/50

Code C:

p.alpha;

select

|| p.beta; ...

|| p.gamma; ...

end;

p.delta

LTS L(C):

A B C Dα

β

γ

δ

32/50

Server Client

SPS PC

C

L(S) w L(Ps) w L(Pc) w L(C)

33/50

q0

q1 q2 q3

α

α α

Server:loop

p.alpha := ...

end

Protocol:[ *( alpha ) ]

Client:x := p.alpha;

y := p.alpha

34/50

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

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

Reasoning - Summary

Code

Procotols

−→ LTS −→

w (simulates)

HM Logic

Also:

FSP / LTSA (Magee & Kramer)Finite State Processes / Labelled Transition System Analyzer

TLA+ (Lamport)Temporal Logic of Actions Plus

37/50

Road Map

Programmingwhat we've done

Principleswhy we've done it

Reasoninghow we know it works

Developmenthow we fit it together

For and againstwhy we bother

38/50

39/50

Requirements

Specification

Design

PL

machine code

40/50

Change moves upwards in the funnel:

spaghetti ??−→ waterfall

structured code −→ SADTStructured Analysis & Design Technique

object-oriented languages −→ OOADObject-Oriented Analysis & Design

aspect-oriented languages −→ AOSDAspect-Oriented Software Development

process-oriented languages ??−→ POMDDProcess-Oriented Model-Driven Design

41/50

Therefore:

To effect change in the

software development process,

we must change the

programming paradigm.

42/50

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

Road Map

Programmingwhat we've done

Principleswhy we've done it

Reasoninghow we know it works

Developmenthow we fit it together

For and againstwhy we bother

44/50

The case against

45/50

The case against

Programming languages are not the problem

45a/50

The case against

Programming languages are not the problem

Object-oriented programming is good enough

45b/50

The case against

Programming languages are not the problem

Aspect-oriented programming is good enough

45c/50

The case against

Programming languages are not the problem

Aspect-oriented programming is good enough

We've hidden the hard bitsCICS, J2EE, CORBA, ...

45d/50

The case against

Programming languages are not the problem

Aspect-oriented programming is good enough

We've hidden the hard bitsCICS, J2EE, CORBA, ...

Introducing a new paradigm is no longer feasible

45e/50

The case for

46/50

The case for

Many distributed applications

46a/50

The case for

Many distributed applications

Multicore processors

46b/50

The case for

Many distributed applications

Multicore processors

Process-oriented programming is ... good

46c/50

The case forMany distributed applications

Multicore processors

Process-oriented programming is ... good

We need software

development

maintenance

growth

adaptation

evolution

refactoring

46d/50

Competition

ABCL/1 Joyce

Ada Mozart/Oz

Cilk Occam-π

Concurrent Pascal SALSA

Erlang SR

47/50

Wrap Up

Objects ... Aspects ... Threads ... Locks ... ×

Hidden guru code ... ×

Modular concurrency ...√

48/50

Erasmus provides ...

safe concurrency

modularity

scalability

modelling capability

weak coupling

testing

49/50

Erasmus provides ...

safe concurrency

modularity

scalability

modelling capability

weak coupling

testing

... we hope!

49a/50

The End

50/50