Ports, Protocols, and Processesusers.encs.concordia.ca/home/g/grogono/Erasmus/ppp-slides.pdf · a...
Transcript of Ports, Protocols, and Processesusers.encs.concordia.ca/home/g/grogono/Erasmus/ppp-slides.pdf · a...
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