36. Is there a calculus for distributed computing?
“The inevitability of the lambda-calculus arises
from the fact that the only way to observe a
functional computation is to watch which output
values it yields when presented with different
input values” [1]
37. Is there a calculus for distributed computing?
“Unfortunately, the world of concurrent
computation is not so orderly. Different notions of
what can be observed may be appropriate in
different circumstances, giving rise to different
definitions of when two concurrent systems have
‘the same behavior’ ” [1]
41. What is π-calculus
“π -calculus is a model of computation for
concurrent systems.” [2]
42. What is π-calculus
“In lambda-calculus everything is a function (...)
In the pi-calculus every expression denotes a
process - a free-standing computational activity,
running in parallel with other process.” [1]
44. What is π-calculus
“It lets you represent processes, parallel
composition of processes, synchronous
communication between processes through
channels, creation of fresh channels, replication of
processes, and nondeterminism.” [2]
45. Syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy.P output prefix
P | Q parallel composition
(νx)P restriction
!P replication
46. Syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy.P output prefix
P | Q parallel composition
(νx)P restriction
!P replication
47. Syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy.P output prefix
P | Q parallel composition
(νx)P restriction
!P replication
48. Syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy.P output prefix
P | Q parallel composition
(νx)P restriction
!P replication
49. Input and output example
Model a program that runs single process P, which
sends message hello on channel x and then
receives a message msg on the same channel x.
97. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → if P → Q reduction under |
98. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → Q | R if P → Q reduction under |
99. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → Q | R if P → Q reduction under |
(νx)P → if P → Q reduction under ν
100. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → Q | R if P → Q reduction under |
(νx)P → (νx)Q if P → Q reduction under ν
101. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → Q | R if P → Q reduction under |
(νx)P → (νx)Q if P → Q reduction under ν
P → if P ≡ P’ Q’ ≡ Q structural congruence
102. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → Q | R if P → Q reduction under |
(νx)P → (νx)Q if P → Q reduction under ν
P → if P ≡ P’ → Q’ ≡ Q structural congruence
103. Reduction rules ⟶
xy.P | x(z).Q → P | [y/z]Q communication
P | R → Q | R if P → Q reduction under |
(νx)P → (νx)Q if P → Q reduction under ν
P → Q if P ≡ P’ → Q’ ≡ Q structural congruence
104. Some examples(1) - PingPong
PING ::= x(ping).x(pong)
PONG ::= x(ping).x(pong)
P ::= PING | PONG
105. Some examples(1) - PingPong
PING ::= x(ping).x(pong)
PONG ::= x(ping).x(pong)
P ::= x(ping).x(pong) | x(ping).x(pong)
124. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)(P | Q)
125. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy)xy.yw.yz | x(y).y(h).y(h))
126. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy)xy.yw.yz | x(y).y(h).y(h))
xy.P | x(z).Q → P | [y/z]Q communication
127. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy)xy.yw.yz | x(y).y(h).y(h))
xy.P | x(z).Q → P | [y/z]Q communication
128. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy)yw.yz | y(h).y(h))
xy.P | x(z).Q → P | [y/z]Q communication
129. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy)yw.yz | y(h).y(h))
xy.P | x(z).Q → P | [y/z]Q communication
130. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy)yz | y(w))
xy.P | x(z).Q → P | [y/z]Q communication
131. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= (νx)((νy) 0 | 0)
132. Some examples(0) - Sending channels
P ::= (νy)xy.yw.yz
Q ::= x(y).y(h).y(h)
R ::= 0
133. Some examples(2) - PingPong
PING ::= x(ping).x(pong)
PONG ::= x(ping).x(pong)
P ::= PING | PONG | PONG
154. Some examples(4) - Race Conditions
P ::= xy | xz | x(w).w(v)
P ::= 0 | xz | y(v)
155. Some examples(4) - Race Conditions
P ::= xy | xz | x(w).w(v)
P ::= 0 | xz | y(v) P ::= xy | 0 | z(v)
156. Some examples(4) - Race Conditions
P ::= xy | xz | x(w).w(v)
P ::= xz | y(v) P ::= xy | z(v)
157. Benefits
● reason about computation
● detect dead-locks
● detect non-determinism
● reason about structure
● good to describe protocols
● a formal framework for providing semantics for
a high-level language
160. Implementation issue...
“This seems quite natural.(...).But there’s a big problem here.
ReceivePorts are not Serializable, which prevents us passing
the ReceivePort r1 to the spawned process. GHC will reject the
program with a type error.” [8]
161. Implementation issue...
“Why are ReceivePorts not Serializable? If you think about it a
bit, this makes a lot of sense. If a process were allowed to send
a ReceivePort somewhere else, the implementation would have
to deal with two things: routing messages to the correct desti‐
nation when a ReceivePort has been forwarded (possibly
multiple times), and routing messages to multiple destinations,
because sending a ReceivePort would create a new copy.” [8]
162. Implementation issue...
“This would introduce a vast amount of complexity to the
implementation, and it is not at all clear that it is a good feature
to allow. So the remote framework explicitly disallows it,
which fortunately can be done using Haskell’s type system.”
[8]
163. Issues
● synchronous by nature
● receiving on send channel - implementation
dilemmas
● notion of creating a named channel
170. Sync π syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy.P output prefix
P | Q parallel composition
(νx)P restriction
!P replication
171. Async π syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy.P output prefix
P | Q parallel composition
(νx)P restriction
!P replication
172. Async π syntax
P, Q, R :: = 0 inert process
x(y).P input prefix
xy output prefix
P | Q parallel composition
(νx)P restriction
!P replication
173. Benefits
● almost all expressive power of classical
pi-calculus
● models asynchronous computation
174. Issues
● Is not a closed theory
● Heating / cooling rules seem like an overkill
● Not as powerful as synchronous version
○ “Comparing the expressive power of the synchronous
and asynchronous pi-calculus” Catuscia Palamidessi
178. ρ-calculus
“The π-calculus is not a closed theory, but rather
a theory dependent upon some theory of names.
(...) names may be tcp/ip ports or urls or object
references, etc. But, foundationally, one might ask
if there is a closed theory of processes, i.e. one in
which the theory of names arises from and is
wholly determined by the theory of processes.” [7]
179. Quoting
“Here we present a theory of an asynchronous
message-passing calculus built on a notion of
quoting. Names are quoted processes, and as such
represent the code of a process.(...) Name-passing,
then becomes a way of passing the code of a
process as a message.” [7]
180. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
181. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
182. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
183. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
184. x⦉P⦊
“Process P will be packaged up as its code, ⌜P⌝,
and ultimately made available as an output at the
port x” [7]
185. x⦉P⦊
“Process P will be packaged up as its code, ⌜P⌝,
and ultimately made available as an output at the
port x” [7]
“The lift operator turns out to play a role
analogous to (νx)”
186. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
187. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
188. ⌝x⌜
“The ⌝x⌜ operator (...) eventually extracts the
process from a name. We say ‘eventually’ because
this extraction only happens when quoted process
is substituted into this expression.” [7]
189. ⌝x⌜
“A consequence of this behaviour is that the ⌝x⌜ is
inert, except under an input prefix” [7]
190. Syntax
P, Q ::= 0 inert process
x(y).P input
⌝x⌜ drop
x⦉P⦊ lift
P | Q parallel
x, y ::= ⌜P⌝ quote
206. Are those different names?
“This question leads to several intriguing and
apparently fundamental questions. Firstly, if
names have structure, what is a reasonable notion
of equality on names? How much computation, and
of what kind, should go into ascertaining equality
on names?” [7]
231. References
1 “Foundational Calculi for Programming Languages” Benjamin C. Pierce
2 "FAQ on π-Calculus" Jeannette M. Wing
3 “A Calculus of Communicating Systems” Robin Milner
4 “Communicating Sequential Processes” C.A.R Hoare
5 https://en.wikipedia.org/wiki/%CE%A0-calculus
6 “The Polyadic Pi-Calculus: a Tutorial” Robin Milner
7 “A Reflective Higher-Ordered Calculus” L.G. Meredith, Matthias Radestock
8 “Parallel and Concurrent Programming in Haskell: Techniques for Multicore”