Zero-safe net models for transactions in Linda
42
Zero-safe net models for transactions in Linda Roberto Bruni Ugo Montanari University of Pisa ConCoord: International Workshop on Concurrency and Coordination Lipari Island, Italy, 6-8 July 2001
description
ConCoord: International Workshop on Concurrency and Coordination Lipari Island, Italy, 6-8 July 2001. Zero-safe net models for transactions in Linda. Roberto Bruni Ugo Montanari University of Pisa. Transaction of the Talk. two design postulates. - PowerPoint PPT Presentation
Transcript of Zero-safe net models for transactions in Linda
Zero-safe net models for transactions in Linda
Roberto BruniUgo Montanari
University of Pisa
ConCoord: International Workshop on Concurrency and CoordinationLipari Island, Italy, 6-8 July 2001
Transaction of the Talktwo design postulates
Petri, Linda, JavaSpaces, join, cham, ambient, , spi …
transactions are useful
in many different flavours
unifying transactions
in a concurrent scenario, via uniform syntax
zero-safe approach
extended, inhibitor arcs, TraLinda concurrent
semantics of Linda
net flavours
examples
conclusion and future work
Common Design Postulates
I. STATES ARE MULTISETS(e.g. of resources, agents, functions, rules,…)facilitates definition of reductions semantics(components can react when “close”)
II. ELEMENTARY ACTIONS CAN ATOMICALLY FETCH/RELEASE SEVERAL COMPONENTS
(synchronized at the event level)concurrent computations arise by state distribution
A Saucerful of Processes
A Saucerful of Processes
A Saucerful of Processes
A Saucerful of Processes
A Saucerful of Processes
On TransactionsI + II = Petri nets, Linda, JavaSpaces, cham, join,
ambient, , spiIII. EXPRESS TRANSACTIONS
(e.g. group events into work units that either completely succeed or have no effect)
important issue to provide reliable services, encoding, refinement/abstraction, …
transactions in a concurrent scenario (as opposed to a sequential or interleaving one)
Some Flavours of Transactions
EX. Transactions in databases (atomic updates, interest in serializability)schedule of primitive update operations must be
“equivalent” to a schedule of atomic updates
[A1:read x; A2:write x][B1:read x; B2:write x]
A1 A2 B1 B2 okB1 B2 A1 A2 okA1 B1 A2 B2 no
More FlavoursEX. Reliable multicast either all processes in a group receive a multicast
or none of them does
EX. Fault tolerant service(e.g. e-commerce: don’t pay if service is
not delivered and vice versa)
One More FlavourEX. Nested transactions
A
D
C
B(1)(2)
(3)
(1)
(2) (3)
(1) fails (2),(3) fails
(2) or (3) fails (1) may still succeed
A Last FlavourEX. Design complex systems via refinement compositionality issuesactivities can vary in durationdistributed commitconsistency of local choicesmove freely between the abstract and the
refined view of systems
Abstraction/Refinement I
Abstraction/Refinement II
Unifying TransactionsAd hoc transaction mechanisms are integrated
in many languages (e.g. BizTalk Orchestration and JavaSpaces)Can we find a uniform way to handle point III
in existing frameworks?Two main issues must be considered:
(i) theoretical characterization of transactions(ii) definition of a distributed interpreter
The convenient way: Uniform syntax for III (like I and II) Visual formalism
Net FlavoursThe simpler model: Petri nets
Progressive enrichments to encompass limitations of the basic paradigm
(see e.g. [Asperti Busi] [Buscemi Sassone])
2
3 2
ba
c d
Coloured (or High Level)
x |y|
1 5 “s”
6
x y
y.y x+3
“ss”
4
ba
c d
structured data as tokens
Reconfigurablec d
x y
y x
ba
x y
ac
c cc c
postsets may depend on read values:
network reconfigurability vs. static connectivity
Dynamic c d
x y
ba ac
a firing can modify the “control”, increasing the set of transitions (very similar to join)
N(x,y)
X
Read Arcsba
c d
multiple concurrent accesses in “reading”
Inhibitor Arcsb
a
c
dincrease expressiveness (reachability is no longer decidable)
t0
t1
t2
e
And Also…with timewith prioritieswith probabilities…ZERO-SAFE
n-safe place: contain at most n tokens in any reachable marking
0-safe place: cannot contain tokens!
but can contain tokens during the execution of a transaction
Zero-Safe NetsAlmost like Petri nets, but…stable placesordinary placeszero places empty in stable markings, tokens
produced must be fetched before commit transactions concurrent execution whose
intermediate states are non-stablegraphically
stable tokens produced during a transaction cannot be reused in the same transaction
ba
c d
z
BehaviourOrdinary nets:
S places, S markings, T transitions t : uv
Zero-Safe netsS stable places, Z zero places, (SZ) S
Z T transitions t : (u,x)(v,y)
uS
u ut : uvT
u vu v u’ v’uu’ vv’
ux vy(u,x) (v,y)
(u,0) (v,0) (uu’,x) (vv’,y’)
(u,x) (v,y)
u v
(u’,y) (v’,y’)
Abstract NetZN zero-safe net, we look for an ordinary Petri net N s.t.
1) SN = SZN
2) N = ZN Informally, the transitions of N are the (concurrent) proofs of transaction steps in ZN: t : uv N u v ZN Not all proofs are necessary, but only an essential subseta) considered up to permutation of concurrent eventsb) cannot be decomposed into shorter proofsResultsi. transactions via free constructionii. abstract net via universal construction (optimal)iii. distributed interpreter based on “net unfolding”
Example: From Free Choice to Non-Deadlocking I
Example: From Free Choice to Non-Deadlocking II
Example: From Free Choice to Non-Deadlocking III
Example: Multicasting I
2
b
a
c
z
new send
receive copyreset
Example: Multicasting II
b
a
c
new
1-to-n1-to-1 1-to-2reset … …
2
2
3
3
n+1
n+1
Zero-Safe and Read ArcsIt is forbidden to first read and then consume a
stable token inside the same transaction!
read token, cannot be fetched
Example: Multicasting III
b
a
c
z
new open
receive
close
reset
Zero-Safe and Inhibitor Arcs
It is forbidden to 0-test zero places!
The net is ambiguous! At the abstract level: Two independent activities or not?
Transactions in Linda
Linda-like process calculusP 0 | M | .P | ?P:P | P+P | PPM a out(a) | rd(a) | in(a) | !in(a) rdp(a) | inp(a)[Busi Gorrieri Zavattaro]: truly concurrent
semantics via nets (employing read and inhibitor arcs)
Net Semantics for Linda
rdp(a)?P:Q
aN(P) N(Q)
Example N(rdp(a)?P:Q)
Ordered vs. Unordered
out(a).P
a
N(P)
Example N(out(a).P)
a
N(P)
out(a).P
a
emission
rendering
emission +rendering
Zero-Safe ApproachBuilt on the net semantics of Linda termslow-level messages vs. high-level messages(zero-safe) (stable)
Typing relation a: {L,H}Atomic prefixing _P
We call TraLinda the resulting process algebra
Net Semantics for TraLinda
Straightforward adaptation of the exisiting one for Linda (stable guards only)
in(a)_out(b).P
a
N(P)
Example N(in(a)_out(b).P)a:L b:H
{out(b).P}
b
More TraLinda Examplesout(a).P in(a).Q
asynchronous communication if a:Hsynchronized communication if a:L
in(a1)_out(z)in(a2)_out(z)in(z)_in(z)_Pai:H z:L atomically fetches a1 and a2
Ordered vs. Unordered IIExample N(out(a).P)
a
N(P)
out(a).P
a
CommitZS approach = a common language for
distributed transactionsHere extended to handle inhibitor arcs
and applied to concurrent modeling of Linda with transactions
Comparison with the previous talkExtension to reconfigurable and dynamic
nets (i.e. join-calculus)two kinds of names (zero and stable)nested transactions (flat vs. hierarchical view)typing discipline and distributed interpreter
