Zero-safe net models for transactions in Linda

1. 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

2. Transaction of the Talk two design postulates Petri, Linda, JavaSpaces,join, cham, ambient, , spi … examples transactions are useful in many different flavours unifying transactions in a concurrent scenario,via uniform syntax net flavours zero-safe approach extended, inhibitor arcs, TraLinda concurrent semantics of Linda conclusion and future work

3. Common Design Postulates • STATES ARE MULTISETS (e.g. of resources, agents, functions, rules,…) facilitates definition of reductions semantics (components can react when “close”) • ELEMENTARY ACTIONS CAN ATOMICALLY FETCH/RELEASE SEVERAL COMPONENTS (synchronized at the event level) concurrent computations arise by state distribution

4. A Saucerful of Processes

5. A Saucerful of Processes

6. A Saucerful of Processes

7. A Saucerful of Processes

8. A Saucerful of Processes

9. On Transactions I + II = Petri nets, Linda, JavaSpaces, cham, join, ambient, , spi • 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)

10. 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 ok B1 B2 A1 A2 ok A1 B1 A2 B2no

11. More Flavours EX. 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 viceversa)

12. One More Flavour EX. Nested transactions C (2) (1) A (1) B (2) (3) (3) D • fails (2),(3) fails • or (3) fails (1) may still succeed

13. A Last Flavour EX. Design complex systems via refinement • compositionality issues • activities can vary in duration • distributed commit • consistency of local choices • move freely between the abstract and the refined view of systems

14. Abstraction/Refinement I

15. Abstraction/Refinement II

16. Unifying Transactions Ad 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: • theoretical characterization of transactions • definition of a distributed interpreter The convenient way: • Uniform syntax for III (like I and II) • Visual formalism

17. Net Flavours a b The simpler model: Petri nets Progressive enrichments to encompass limitations of the basic paradigm (see e.g. [Asperti Busi] [Buscemi Sassone]) 2 3 2 c d

18. 4 “ss” Coloured (or High Level) a b 1 5 “s” x y x  |y| y.y x+3 6 c d structured data as tokens

19. c c c c Reconfigurable a b c a d c x y y x x y postsets may depend on read values: network reconfigurability vs. static connectivity

20. Dynamic a b c a d c x y X N(x,y) a firing can modify the “control”, increasing the set of transitions (very similar to join)

21. Read Arcs a b c d multiple concurrent accesses in “reading”

22. Inhibitor Arcs b a t1 e t0 t2 c d increase expressiveness (reachability is no longer decidable)

23. And Also… • with time • with priorities • with 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

24. Zero-Safe Nets Almost like Petri nets, but… • stable places ordinary places • zero places empty in stable markings, tokens produced must be fetched before commit • transactions concurrent execution whose intermediate states are non-stable • graphically a b stable tokens produced during a transaction cannot be reused in the same transaction z c d

25. Behaviour • Ordinary nets: • Splaces,Smarkings,Ttransitionst : uv • Zero-Safe nets • Sstable places,Zzero places,(SZ) S  Z • Ttransitionst : (u,x)(v,y) uS t : uvT u  v u’  v’ u  u u  v uu’ vv’ (u,x)  (v,y)  ux vy (u’,y)  (v’,y’)  (u,0)  (v,0)  (u,x)  (v,y)  (uu’,x) (vv’,y’)  u  v 

26. Abstract Net ZNzero-safe net, we look for an ordinary Petri net N s.t. • SN = SZN • N = ZN Informally, the transitions of N are the (concurrent) proofs of transaction steps in ZN: t : uv  N u v  ZN Not all proofs are necessary, but only an essential subset • considered up to permutation of concurrent events • cannot be decomposed into shorter proofs Results • transactions via free construction • abstract net via universal construction (optimal) • distributed interpreter based on “net unfolding”    

27. Example: From Free Choice to Non-Deadlocking I

28. Example: From Free Choice to Non-Deadlocking II

29. Example: From Free Choice to Non-Deadlocking III

30. Example: Multicasting I a b new send 2 copy reset receive z c

31. Example: Multicasting II a b n+1 new 3 2 … … reset 1-to-1 1-to-2 1-to-n 2 3 n+1 c

32. Zero-Safe and Read Arcs It is forbidden to first read and then consume a stable token inside the same transaction! read token, cannot be fetched

33. Example: Multicasting III a b new open reset receive z close c

34. 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?

35. Transactions in Linda Linda-like process calculus P  0 | M | .P | ?P:P | P+P | PP M  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)

36. Net Semantics for Linda Example N(rdp(a)?P:Q) rdp(a)?P:Q a N(P) N(Q)

37. Ordered vs. Unordered Example N(out(a).P) out(a).P out(a).P emission emission + rendering rendering a a N(P) N(P) a

38. Zero-Safe Approach Built on the net semantics of Linda terms low-level messages vs. high-level messages (zero-safe) (stable) • Typing relation a:{L,H} • Atomic prefixing _P We call TraLinda the resulting process algebra

39. Net Semantics for TraLinda Straightforward adaptation of the exisiting one for Linda (stable guards only) Example N(in(a)_out(b).P)a:L b:H in(a)_out(b).P a {out(b).P} b N(P)

40. More TraLinda Examples • out(a).P  in(a).Q • asynchronous communication if a:H • synchronized communication ifa:L • in(a1)_out(z)in(a2)_out(z)in(z)_in(z)_P • ai:Hz:L atomically fetches a1 and a2

41. Ordered vs. Unordered II Example N(out(a).P) out(a).P a N(P) a

42. Commit • ZS approach = a common language for distributed transactions • Here extended to handle inhibitor arcs and applied to concurrent modeling of Linda with transactions • Comparison with the previous talk • Extension 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