Programming paradigms for concurrency
Download
1 / 45

Programming Paradigms for Concurrency - PowerPoint PPT Presentation


  • 74 Views
  • Uploaded on

Programming Paradigms for Concurrency. Lecture 11 Part III – Message Passing Concurrency. TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A A A A A A A A A A A A A. Formal Semantics for MP Programs: The ¼ -Calculus. The ¼ -Calculus.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Programming Paradigms for Concurrency' - landen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Programming paradigms for concurrency

Programming Paradigms for Concurrency

Lecture 11

Part III – Message Passing Concurrency

TexPoint fonts used in EMF.

Read the TexPoint manual before you delete this box.: AAAAAAAAAAAAA



The calculus
The ¼-Calculus

  • developed by Milner, Parrow, and Walker in the early 1990’s as a generalization of value-passing CCS.

  • provides computational model for concurrent and mobile systems

  • many applications: formal models for

    • Message passing programs

    • Web services

    • Business Processes

    • Security protocols

    • Biological systems


Reading material
Reading Material

Introductory Reading:

  • Communication and Mobile Systems: the ¼-calculus. Milner, Cambridge University Press, 1999

    Advanced Reading:

  • The ¼-calculus: a Theory of Mobile Processes. Sangiorigi and Walker, Cambridge University Press, 2003.

  • A Calculus of Mobile Processes, Parts I and II. Milner, Parrow, and Walker, Information and Computation 100:1, 1992.


Ping pong actors
Ping Pong Actors

Pong

Ping

Msg

sender


Ping pong actors1
Ping Pong Actors

Pong

Ping

Msg

Msg

sender


Ping pong actors2
Ping Pong Actors

sender

Pong

Ping

Msg


Ping pong actors in scala
Ping Pong Actors in Scala

valpingTd = actor {

loop {

react { caseMsg(sender) => sender ! Msg(self) }

}

}

valpongTd = actor {

loop {

react { caseMsg(sender) => sender ! Msg(self) }

}

}

valinitTd = actor { pongTd ! Msg(pingTd) }

pingTd.start; pongTd.start; initTd.start


Ping pong actors in cml
Ping Pong Actors in CML

datatypemsg = MSG of msgchan

funpongTd (pong : msgchan) =

case recv pong of

MSG(sender) =>

send (sender, MSG(pong));

pongTd (pong)

end

funpingTd (ping : msgchan) =

case recv ping of

MSG(sender) =>

send (sender, MSG(ping));

pongTd (ping)

end

fun initTd (ping, pong) = send(pong, MSG(ping))


Ping pong actors in cml1
Ping Pong Actors in CML

let val ping = channel ()

valpong = channel ()

in

spawn (fn () => initTd(ping, pong));

spawn (fn () => pingTd(ping));

spawn (fn () => pongTd(pong))

end


Ping pong actors in the calculus
Ping Pong Actors in the ¼-calculus

behavior of threads is defined by parametric equations of

process IDs and process terms

equations can be (mutually) recursive

system is given by a process term referring to the defined process IDs


Ping pong actors in the calculus1
Ping Pong Actors in the ¼-calculus

funpongTd (pong : msgchan) =

case recv pong of

MSG(sender) =>

send (sender, MSG(pong));

pongTd (pong)

end

receive channel on pong

and bind it to sender


Ping pong actors in the calculus2
Ping Pong Actors in the ¼-calculus

funpongTd (pong : msgchan) =

case recv pong of

MSG(sender) =>

send (sender, MSG(pong));

pongTd (pong)

end

send pong back on sender


Ping pong actors in the calculus3
Ping Pong Actors in the ¼-calculus

funpongTd (pong : msgchan) =

case recv pong of

MSG(sender) =>

send (sender, MSG(pong));

pongTd (pong)

end

and recurse


Ping pong actors in the calculus4
Ping Pong Actors in the ¼-calculus

let val ping = channel ()

valpong = channel ()

in

spawn (fn () => initTd(ping, pong));

spawn (fn () => pongTd(pong));

spawn (fn () => pingTd(ping))

end

create two fresh private channels and bind them to ping and pong

pronounced “new”


Ping pong actors in the calculus5
Ping Pong Actors in the ¼-calculus

let val ping = channel ()

valpong = channel ()

in

spawn (fn () => initTd(ping, pong));

spawn (fn () => pongTd(pong));

spawn (fn () => pingTd(ping))

end

spawn all threads


Ping pong actors in the calculus6
Ping Pong Actors in the ¼-calculus


The calculus1
The ¼-Calculus

  • There exist many different variants of the ¼-calculus using different notations and slightly different semantics.

  • We use one particular variant and stick to it.


Names
Names

In the ¼-calculus channels are called names.

Names serve both as communication channels and as the data that is sent when threads synchronize.

We assume an infinite set of names:


Syntax of process terms
Syntax of Process Terms

nil process (termination)

parallel composition of P and Q

nondeterministic choice between P and Q

generation of fresh name x with scope P

reception of y on x with continuation P

sending of y on x with continuation P

replication of P

restriction

input prefix

output prefix

Notational conventions:


Bound and free names
Bound and Free Names

Restriction and input prefix bind names in a process term. Occurrences of names in a process term that are not bound are called free.

The function fn returns the set of free names of a process term:

If fn(P ) = ; then P is called closed.


Equivalence
®-Equivalence

We consider process terms P and Q equivalent if they are equal up to consistent renaming of bound names (denoted by P´®Q)

For example:

Can we replace x with z?

But we have


Name substitution
Name Substitution

We write P [y/x] for the process obtained from P by replacing all free occurrences of name x by name y.

We call [y/x] a name substitution.

Substitutions use implicit ®-renaming to avoid capturing of free occurrences of names. For instance:

We write [y1,…,yn/x1,…,xn] for [y1/x1]…[yn/xn]


Labeled transition system
Labeled Transition System

A labeled transition system (LTS) is a tupleM =hS, L, !, Iiwith

S a nonempty set of states

L a nonempty set of labels

I µS the set of initial states

!µS£L£S the transition relation

For a transition we write


Executions and traces
Executions and Traces

An execution± of an LTS M =hS, L, !, Ii is a sequence of consecutive transitions starting in an initial state s02I

If ± is finite then its final state sf has no outgoing transitions.

A trace¾ is the projection of an execution to its labels

We denote by Traces(M) the set of all traces of M.


Semantics of process terms
Semantics of Process Terms

The semantics of a process term P is defined operationally by associating a labeled transition system MP with P.

  • MP captures the behavior of P in all possible process contexts.

  • the initial state of MP is P itself

  • the states of MP are process terms describing the continuations of partial executions

  • the transition relation is defined in terms of transition rules that capture synchronization between threads

  • the labels of MP are actions that encode whether a process synchronizes internally or with the environment


Structural congruence
Structural Congruence

The behavior of two ®-equivalent processes P and Q should be indistinguishable, i.e., ´® should be a congruence for the transition relation:

There are other such structural equivalences. For instance, one would expect that the following processes behave equally:

P | Q and Q | P

We capture all these cases in a structural congruence relation´.





Actions
Actions

Transitions of process terms are labeled with actions. Actions describe what kind of synchronization the process term performed.

Actions:


Silent action
Silent Action

means P synchronizes internally resulting in Q

Example:


Input action
Input Action

means P can receive a w over x resulting in Q[w/y]

Example:


Free output action
Free Output Action

means P can send the free (i.e., publicly known) name y over x to the environment, resulting in Q

Example:

note that there is also a silent action possible:


Bound output action
Bound Output Action

means P can send the bound name y over x to the environment, resulting in Q (i.e., y is leaked to the environment and no longer private to P)

Example:

again there is an alternative silent action possible:


Free and bound names of actions
Free and Bound Names of Actions

We denote by n(®), fn(®), and bn(®) the names, free names, and bound names of action ®:





Ping pong actors in the calculus7
Ping Pong Actors in the ¼-calculus

Can we express recursive equations in our calculus?


Polyadic calculus
Polyadic¼-Calculus

Multiple names can be communicated in one step


Monadic encoding of polyadic calculus
Monadic Encoding of Polyadic Calculus

We can encode the polyadic calculus in the monadic one using serialization:

for some fresh name z

Why is the following encoding incorrect?


Encoding recursive equations
Encoding Recursive Equations

Given a recursive definition of a process identifier A

and a process term P that uses this definition. We can encode the behavior of A in P as follows:

  • choose a fresh name y not occuring in P or Q

  • let Py and Qy be P and Q, where each occurrence of process identifier A is replaced by

  • replace P by



Outlook behavioral equivalence
Outlook: Behavioral Equivalence

PongTd(x) and PingTd(x) are ®-equivalent for all names x, so we can safely replace one by the other in any context.

Next week: In general, when can we safely replace one process term by another one? They should surely have the same set of traces, but is that enough?


ad