Download presentation
Presentation is loading. Please wait.
1
1 Semantics Q1 2007 S EMANTICS (Q1,’07) Week 5 Jacob Andersen PhD student andersen@daimi.au.dk
2
2 Semantics Q1 2007 News… Exam Date & Time (Preliminary): –Wednesday October 31 st 9.00 – 13.00 Page on CCS tools.
3
3 Semantics Q1 2007 Outline Type Checking (from last week) Concurrency vs. Sequentiality CCS: "Calculus of Communicating Systems" By-example (one construction at a time) Syntax of CCS 7 linguistic constructions(!) Semantics of CCS 1 page(!) Describing processes with CCS CCS tools
4
4 Semantics Q1 2007 T YPE C HECKING D EFINITIONS
5
5 Semantics Q1 2007 Adding Boolean Variables: Let B ++ Consider language Let B ++: –Mixed Expressions ( e Exp): –Definitions (d Def): –Note: The type of a var is now context dependent I.e. a context-free (grammar) approach will not suffice –Examples: ? ? … e ::= n | t | x | ~ e | e e’ | e ? e’ : e” | let d in e d ::= nil | x = e | d ; d’ | d and d’ | d in d’ { +, -, *, =, or } …where: x or tt x * x type definition (annotation) { bool, int } …where:
6
6 Semantics Q1 2007 Static Semantics: Let B ++ FV E, DV D and FV D as before …adding: We now need type environments: Type = { bool, int } Define static semantics (type checking rel’s): “ e has type (given type environment )” “ d yields type env. (given type env. )” FV E ( e ? e’: e” ) = FV E ( e ) FV E ( e’ ) FV E ( e” ) TEnv V = Var Type |- e : |- d :
7
7 Semantics Q1 2007 Static Semantics (expressions) Expressions: [ NUM ] E |- n : int |- t : bool [ TVL ] E [ VAR ] E |- x : (x) [ VAR ] E |- ~ e : bool |- e : bool [ LET ] E |- let d in e : |- d : [ ] |- e : [ IFE ] E |- e 0 ? e 1 : e 2 : |- e 0 : bool |- e 1 : 1 |- e 2 : 2 = 1 =2 = 1 =2 [ BOP ] E |- e 0 e 1 : type ( 0, 1 ) |- e 0 : 0 |- e 1 : 1
8
8 Semantics Q1 2007 Static Semantics (definitions) Definitions: [ NIL ] D |- nil : [] [ DEF ] D |- x = e : [x ] |- e : ’ = ’ = ’ [ SEQ ] D |- d 0 ; d 1 : 0 [ 1 ] |- d 0 : 0 [ 0 ] |- d 1 : 1 [ AND ] D |- d 0 and d 1 : 0 1 |- d 0 : 0 |- d 1 : 1 [ IN ] D |- d 0 in d 1 : 1 |- d 0 : 0 [ 0 ] |- d 1 : 1 DV( d 0 ) DV( d 1 ) = Ø Note: combined environment Note: only last environment Note: disjoint environment Note: type check
9
9 Semantics Q1 2007 Dynamic Semantics: Let B ++ Type Environment (Compile-time): Type = { bool, int } Environment (Runtime): Val = B Z, B = { tt, ff } –Define type correspondence relation ‘~’: –Note: TEnv = Var Type Env = Var Val ~ x V: ( x ) = bool ( x ) B ( x ) = int ( x ) Z ( 0 ~ 0 1 ~ 1 ) 0 [ 1 ] ~ 0 [ 1 ]
10
10 Semantics Q1 2007 Exp. Transition System for Let B ++ Let++ Expression Configurations: Let B ++ Expression Configurations: – Var Type: Env := »i.e., “only type corresponding runtime environments” = { | |- wfe e } T = { | z Z } only well-formed exps = { | Env : |- e : } T = { | Env r B Z } { ( Var B Z ) | ~ }
11
11 Semantics Q1 2007 Def. Transition System for Let B ++ Let++ Definition Configurations: Let B ++ Definition Configurations: – Var Type: Env := »i.e., “only type corresponding runtime environments” V = { | |- wfd d } only well-formed defs T V = { } = { | Env : |- V d : } T = { | Env } { ( Var B Z ) | ~ }
12
12 Semantics Q1 2007 Exp. Dynamic Semantics: Let B ++ SOS of Expressions for Let B ++: –E.g. [LET]: [ LET 2 ] [ LET 3 ] [ LET 1 ] Env |- let d in e let d’ in e |- d d’ |- let 0 in r r |- let 0 in e let 0 in e’ [ 0 ] |- e [ 0] e’ 0 ~ 00 ~ 0
13
13 Semantics Q1 2007 Def. Dynamic Semantics: Let B ++ SOS of Definitions for Let B ++: –E.g [SEQ]: [ SEQ 2 ] [ SEQ 3 ] [ SEQ 1 ] |- d 0 ; d 1 d 0 ’ ; d 1 |- d 0 d 0 ’ |- 0 ; 1 0 [ 1 ] |- 0 ; d 1 0 ; d 1 ’ [ 0 ] |- d 1 [ 0] d 1 ’ Env 0 ~ 00 ~ 0
14
14 Semantics Q1 2007 C ONCURRENCY VS. S EQUENTIALITY
15
15 Semantics Q1 2007 Concurrency vs. Sequentiality Sequential programming: Describe computation as a “reduction” of expressions to values Inherently deterministic Termination often desirable Resulting value is of primary interest and focus Concurrent programming: Describe execution as “process evolution” Inherently non-deterministic Non-termination often desirable (Op.Sys., Control sys, Cell-phone, …) Describe possible executions (aka. execution traces) Describe possible interactions during execution Describe interaction with an environment Resulting “value” is not (necessarily) interesting
16
16 Semantics Q1 2007 Concurrency is much Harder Harder than sequential programming: Huge number of possible executions Inherently non-deterministic Parallelism conceptually harder Consequences: Programs are harder to write! Programs are harder to debug! Errors are not always reproducible New kinds of errors possible: »Deadlock, starvation, priority inversion, interference, …
17
17 Semantics Q1 2007 Concurrency Problems Therac-25 Radiation Therapy –’85-’87 Massive overdoses (6 deaths / amputations)! Mars Pathfinder –July ’97 Periodic resets (on mars)! Windows 95/98 w/ Device Drivers –late ’90es Dysfunction (“blue screen of death”)!
18
18 Semantics Q1 2007 Concurrency Problems (cont’d) Mobile Phones –’00-… Freeze and odd behaviors (really annoying)! Cruise Control System Model –’86 [Grady Booch] Accellerated after car ignition (car crashes)! …
19
19 Semantics Q1 2007 Problem: System Development? In the presence of all these errors: deadlock, starvation, priority inversion, interference, anti-cooperation, un-intended execution traces, un-fairness, … How to…: 1. …design a system that “works” ? 2. …verify that the system is “safe” ? 3. …verify that the system “meets its specification” ? …and: What does “works”, “safe”, and “to meet a specification” mean ?!?
20
20 Semantics Q1 2007 Solution: Modelling “Models come to the rescue”: Create models (~ architecture, bridge construction, …) Note: “Errors are much cheaper to commit in models than in implementations”
21
21 Semantics Q1 2007 Dictionary: “ model ” In this course (we use): 3+4 : as in “Model-based design” (designing a model of a concurrent system) 12 : as in “Model-checking” (checking implementation against declarative (logic) specification) Main Entry: 1 mod·el Pronunciation: 'mä-d & l Function: noun Etymology: Middle French modelle, from Old Italian modello, from (assumed) Vulgar Latin modellus, from Latin modulus small measure, from modus 1 obsolete : a set of plans for a building 2 dialect British : COPY, IMAGE 3 : structural design 4 : a usually miniature representation of something; also : a pattern of something to be made 5 : an example for imitation or emulation 6 : a person or thing that serves as a pattern for an artist; especially : one who poses for an artist 7 : ARCHETYPE 8 : an organism whose appearance a mimic imitates 9 : one who is employed to display clothes or other merchandise : MANNEQUIN 10 a : a type or design of clothing / b : a type or design of product (as a car) 11 : a description or analogy used to help visualize something (as an atom) that cannot be directly observed 12 : a system of postulates, data, and inferences presented as a mathematical description of an entity or state of affairs 13 : VERSION Webster’s(“ model ”):
22
22 Semantics Q1 2007 Modelling: Level of Abstraction Consider a client/server system: Extremely abstract (high level of abstraction): » Appropriate (level of abstraction) for … : » Extremely concrete (low level of abstraction): » Universe = event.Universe def NAND_Gate =... Transistor =... Accumulator =...... Client =... def Server = request.process.reply.Server Client = calc.request.wait.reply.Client Database =... higher level of abstraction def
23
23 Semantics Q1 2007 Solution: Modelling “Models come to the rescue”: Create models (~ architecture, bridge construction, …) Formal modelling (e.g., CCS) permits: (Offline) Reasoning understanding (Runtime) Testing confidence (C-time) Property Verification safety (C-time) Specification Verification correctness “Never send a human to do a machine’s job” -- A.Smith (’99) auto- mate Note: “Errors are much cheaper to commit in models than in implementations”
24
24 Semantics Q1 2007 Methodology: Model-based Design Design abstract model Decompose model Reason/Test/Verify model »individual parts and whole Recompose insights »make model safe Impl. concrete program concretize REAL PROBLEM SAFE MODEL SAFE PROGRAM abstract ? ? ? ? MODEL test reason verify
25
25 Semantics Q1 2007 CCS: Why a Calculus (pl. Calculi) Compositional: || »Break things into (several) smaller things Algebraic: , , … »Intuitive ideal (also eases automated verification) Syntactic: and … »Provide basis for programming languages P | QPQ big P + Q Q + P P | Q Q | P P P’ P | Q P’ | Q Q Q’ P | Q P | Q’ [ PAR 1 ] [ PAR 2 ]
26
26 Semantics Q1 2007 Parallel- vs. Concurrent Programming Strategy: –Optimal strategy for a particular goal –Use available resources efficiently Safety: –Conceptually independent players –Control interaction and “rules” The Football Match Analogy: “An analogy that one can make is with football*; - the coach of the team is a parallel programmer while - the referee is a concurrent programmer” -- [P.Panangaden, ’96] The Referee (~ the concurrent programmer): -- Make sure what is happening is a soccer match The Trainer (~ the parallel programmer): -- Make sure my agents are performing “optimally” */ interpret appropriately on either side of the Atlantic
27
27 Semantics Q1 2007 C ALCULUS OF C OMMUNICATING S YSTEMS CCS: Calculus of Communicating Systems [ Robin Milner, ’89 ]
28
28 Semantics Q1 2007 Concurrency and Communication Concurrency: Parallel processes (construction ‘ P|Q ’) »Abstract away (physical) processors »Abstract away diff. in real- vs pseudo-parallelism Communication: Process synchronization (aka. hand-shaking) »Abstract away communication protocol »Abstract away actual values passed
29
29 Semantics Q1 2007 Example: a process modelling a CS student: Interface: Process name: CS Input action(s):{ coke } Output action(s):{ coin, exercise } Behavior of the process described by a CCS program Process Interface exercise coin coke
30
30 Semantics Q1 2007 The Inactive Process: “ 0 ” The inactive process: (aka. “the zero process” or “the nil process”) »Performs no action whatsoever! Note that it offers: »the prototypical behavior of a deadlocked process (that cannot proceed any further in its execution) Example: 0 0
31
31 Semantics Q1 2007 Action Prefixing: “ .P ” Action Prefixing: Can perform action, , after which it behaves like process, P Example(s): Match: Complex match .P strike.0 take.strike.0
32
32 Semantics Q1 2007 Named Process: “ K ” Named Process: Behaves just like the (statically named) process, K Example(s): K Match = strike.0 SingleCokeDisp = coin.coke.0 def
33
33 Semantics Q1 2007 Recursive Processes Recursive Processes (though naming) Example: Expanding the definition we get: » Clock = tick.Clock def Clock = tick.Clock = tick.tick.Clock = tick.tick.tick. ….tick.Clock … …
34
34 Semantics Q1 2007 Non-deterministic Choice: “ P+Q ” Non-deterministic choice: Non-deterministic choice between processes P and Q »Initially has the capabilities of both P and Q ; but performing an action from P, say, will pre-empt further execution of Q. Example: P+Q Disp = coin.(coke.Disp + sprite.Disp) def coke sprite or
35
35 Semantics Q1 2007 Parallel Composition: “ P|Q ” Parallel Composition: Any independent interleavings of processes P and Q »Also: may communicate (hand-shake): process P using input action, a; process Q corresponding output action, a (or vice versa) Example: Student: Coke Machine: P|Q Stud = read.coin.coke.Stud def CokeM = coin.coke.CokeM def CokeM | Stud
36
36 Semantics Q1 2007 Parallel Composition (cont’d) Stud | CokeM (Stud | CokeM) | Stud (Stud | CokeM) | CokeM StudCokeM [ > ] read coke coin coke
37
37 Semantics Q1 2007 Restriction: “ P\a ” Restriction (private name): Behaves just like P, except cannot make a or a actions (except within P ) »Reminiscent of local variables (in private scope) Example: P\a (Stud | CokeM) \ coin \ coke ((Stud | CokeM) \ coin \ coke) | Stud
38
38 Semantics Q1 2007 Action Relabelling: “ P[f] ” Action Relabelling: Behaves like P, except that actions are renamed according to action renaming function, f »Permits parameterized reuse of processes Examples: P[f] VendingMachine = coin.item.VendingMachine CokeMachine = VendingMachine[coke/item] MarsMachine = VendingMachine[mars/item] def Note: relabel inputs to inputs (and corresponding outputs to outputs) def
39
39 Semantics Q1 2007 S YNTAX FOR CCS
40
40 Semantics Q1 2007 Input, output (and internal) action Actions: Set of Channel Names (input) Set of Channel Co-Names (output) Special silent (invisible/internal) action tau Note: inputs and outputs are complementary: »Communication: hand-shake on a and a only (no values) Metavariables: a A a = a a L = A A Act = L { }
41
41 Semantics Q1 2007 CCS Syntax CCS Syntax: “0”// inaction “ .P ”// action prefix, Act “ P+P ”// non-deterministic choice “ P|P ”// parallel composition “ P\L ”// restriction (private name), L ⊆ L “ P[f] ”// action relabelling “ K ”// process variable, K K P ::= 0 | .P | P+P | P|P | P\L | P[f] | K K 1 = P 1, K 2 = P 2, … def a: f(a) = f(a) f( ) = f:Act Act … where Note: restrictions on f
42
42 Semantics Q1 2007 Alternative Syntax Alternative Syntax (that we will also use): –Parameterized sum: i I P i for P 0 + P 1 + … + P n –Inactive process (as empty sum): i Ø P i for 0 –Restriction (by element): P \ a for P \ {a}
43
43 Semantics Q1 2007 Algebraic Operator Precedence 1. Restriction and relabelling “ P\L ” “ P[f] ” 2. Action prefixing “ .P ” 3. Parallel composition “ P|Q ” 4. Summation “ P+Q ” –Q: How is “ R+a.P|b.Q\L ” then to be read ? A: “ R+((a.P)|(b.(Q\L))) ” ! tightest
44
44 Semantics Q1 2007 SOS FOR CCS
45
45 Semantics Q1 2007 SOS for CCS Structural Operational Semantics: Q: why (tau) in communication “ P|Q ” (instead of propagating a or a ) ? ~ “the unobservable hand-shake” [ RES ] [ REL ] [ COM 1 ] [ COM 2 ] [ COM 3 ] [ ACT ] [ SUM j ][ CON ]
46
46 Semantics Q1 2007 D ESCRIBING PROCESSES WITH CCS
47
47 Semantics Q1 2007 Transition Diagram Transition Diagram: A visualization of a Labelled Transition System: »Configurations annotated with processes (e.g. ) »Transitions annotated with actions (e.g. ) a.0 | a.0 0 | a.0a.0 | 0 0 | 0 a a a a a.0 | 0 a
48
48 Semantics Q1 2007 Traces Definition: A “trace”, ω=[α 1,…, α k ] Act* (k ≥ 0), of a process P is a sequence of actions such that the following sequence of configurations can be derived from P: A trace can be the empty sequence [] We use the constant ε ≝ [] traces(P): The set of all traces of P. The set of traces, traces(P), of a process P is ”closed under prefix”, i.e. if ω traces(P) then this is also the case for any prefix of ω. P → P 1 → … → P k α1α1 α2α2 αkαk
49
49 Semantics Q1 2007 Example: Traces traces( ) = {ε,a,a, ,aa,aa} For more complex traces use regular expressions a.0 | a.0 0 | a.0a.0 | 0 0 | 0 a a a a a.0 | a.0
50
50 Semantics Q1 2007 Example Derivation Assume: Consider: A = a.A (b.0|(A|a.0))[c/a] ? def (b.0 | (A | a.0)) [c/a] (b.0 | (A | a.0)) [ REL ] (A | a.0) [ COM 2 ] A a.A [ COM 1 ] [ CON ] [ ACT ] A = a.A def c a a a a [ RES ] [ REL ] [ COM 1 ] [ COM 2 ][ COM 3 ] [ ACT ] [ SUM j ][ CON ] c (b.0 | (A | a.0)) [c/a] (b.0 | (A | a.0)) (A | a.0) A A
51
51 Semantics Q1 2007 Example: Lock ("Mutual Exclusion") Example: ("mutex") Lock Q: How are the critical enters and exits related ? »A: never two enters without exit in between Mutex = (User | Lock) \ {acq,rel} User = acq.enter.exit.rel.User Lock = acq.rel.Lock def System = (User | Lock | User’) \ {acq,rel} def User’ = User[enter’/enter,exit’/exit] def // critical region aka. a "semaphore" acq rel Sema = p.v.Sema "Probeer te verlagen" (Dutch: try to decrease) "Verhoog" (Dutch: increase) E. Dijkstra Historically: Lock def
52
52 Semantics Q1 2007 CCS T OOLS
53
53 Semantics Q1 2007 Concurrency Workbench [ Concurrency Workbench ]Concurrency Workbench P testing (interactive simulation) verification (via logic formulae) dump transition graph (NFA) ... [ http://homepages.inf.ed.ac.uk/perdita/cwb/summary.html ] http://homepages.inf.ed.ac.uk/perdita/cwb/summary.html [ /users/courses/dSem/bin/cwb ]
54
54 Semantics Q1 2007 The Concurrency Workbench CWB: Recommendation: try it out (before the exam)! Command: input “PandQ.ccs”; Command: sim(P); // run the built-in simulator Command: output “P.graph”; // name output file Command: graph(P); // output for CCS visualizer and simulator Command: strongeq(P,Q); // strong bisimilarity CWB’s answer Command: eq(P,Q); // weak bisimilarity CWB’s answer
55
55 Semantics Q1 2007 CCS Visualizer and Simulator [ CCS Visualizer and Simulator ]CCS Visualizer and Simulator [ http://www.brics.dk/bisim/ ] http://www.brics.dk/bisim/ [ /users/courses/dSem/bin/cv ] [ /users/courses/dSem/bin/tbgg ]
56
56 Semantics Q1 2007 "Three minutes paper" Please spend three minutes writing down the most important things that you have learned today (now). After 1 day After 1 week After 3 weeks After 2 weeks Right away
57
57 Semantics Q1 2007 Next week: Equivalences, Bisimulation, and Games Any Questions?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.