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 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 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
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
Cell Main Main = (); Main(); 6/50
Cell Main prot = [ ]; Main = (); Main(); 6a/50
Process prot serverProc clientCell Main 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
prot serverProc clientProcess clientCell Main 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
p q p q p q p q p q p q pq pq p q filter p q p q p q filter filter filter filter filter filter filter filter filter filter filter 12/50
filter 12a/50
Semantics vs. Deployment p p ch square client squareCell clientCell main 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 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
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
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 communicates no race conditions 19/50
# P1 # P3 V1 V2 P2 C2 C1 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 protocols details 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 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
26/50
Labelled Transition System (LTS): Q = { q 0 , q 1 , q 2 , q 3 } , L = { α } , = { ( q 0 , α, q 0 ) , ( q 1 , α, q 2 ) , ( q 2 , α, q 3 ) } . T q 0 q 1 q 2 q 3 α α α 27/50
Strong Simulation: S ⊆ Q × Q → p ′ then If ( p, q ) ∈ S and p α − there exists q ′ ∈ Q such that ( p ′ , q ′ ) ∈ S and q α → q ′ . − p q S α α S p ′ q ′ 28/50
q 0 q 1 q 2 q 3 α α α S = { ( q 1 , q 0 ) , ( q 2 , q 0 ) , ( q 3 , q 0 ) } is a strong simulation. 29/50
If · ( Q, L, T ) is a LTS · A ⊆ Q · B ⊆ Q · S ⊆ A × B is a strong simulation ( A is simulated by B ) A ⊑ B then ( B simulates A ) B ⊒ A ⊒ 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
P S P C S C Server Client L ( S ) ⊒ L ( P s ) ⊒ L ( P c ) ⊒ L ( C ) 33/50
q 0 q 1 q 2 q 3 α α α Server: Protocol: Client: loop [ *( alpha ) ] x := p.alpha; p.alpha := ... y := p.alpha end 34/50
Hennessy-Milner Logic Syntax: (states satisfying X ) = X F (all states) | tt (no states) | ff (intersection) | F 1 ∧ F 2 (union) | F 1 ∨ F 2 (some α -trans − → F ) | � α � F (all α -trans − → F ) | [ α ] F 35/50
Semantics (with respect to an LTS ( Q, L, T ) ): [ [ · ] ] : Σ → P ( Q ) → P ( Q ) [ [ X ] ]( S ) = S [ [ tt ] ]( S ) = Q [ [ ff ] ]( S ) = ∅ [ [ F 1 ∧ F 2 ] ]( S ) = [ [ F 1 ] ]( S ) ∩ [ [ F 2 ] ]( S ) [ [ F 1 ∨ F 2 ] ]( S ) = [ [ F 1 ] ]( S ) ∪ [ [ F 2 ] ]( S ) ]( S ) = { p | ∃ p ′ ∈ S . p → p ′ } α [ [ � α � ] − → p ′ ⇒ p ′ ∈ S } ]( S ) = { p | ∀ p ′ . p α − [ [ [ α ] ] 36/50
Reasoning - Summary Code ⊒ (simulates) LTS − → − → Procotols 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 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
39/50
Requirements Specification Design PL machine code 40/50
Change moves upwards in the funnel: ?? spaghetti → waterfall − structured code − → SADT Structured Analysis & Design Technique object-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
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 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
The case against 45/50
The case against Programming languages are not the problem 45a/50
Recommend
More recommend
