1 Formal Models for Distributed Negotiations Transactions in Linda Roberto Bruni Dipartimento di Informatica Università di Pisa XVII Escuela de Ciencias Informaticas (ECI 2003), Buenos Aires, July

Formal Models for Distributed Negotiations2 Zero-Safe Approach Zero-Safe nets are based on a two-level classification of resources Stable – Observable – Persistent Zero – Temporary – Volatile This idea can be easily exported from Petri nets to other formalisms whenever States are multisets Elementary actions can fetch and release resources Outcome Express transactions in a concurrent scenario Related refined / abstract views of the same system

Formal Models for Distributed Negotiations3 Adding Transactions to Linda We have already seen net models for Linda Places model messages and processes We can apply the Zero-Safe approach Get some insights on a choice of language primitives for expressing transactions Surprisingly, concurrent semantics is more natural than interleaving semantics Refined / abstract views Problem Linda requires contextual arcs

Formal Models for Distributed Negotiations4 Zero-Safe Nets with Read Arcs The combined use of zero-safe places and read arcs is not problematic Crucial point is whether to forbid or not that a stable token is read (possibly many times) and then also fetched during the same transaction We consider the semantics that forbids these behaviors Regarding read arcs on zero safe places can be dealt with for simplicity and uniformity (see why in a few slides) read arcs on zero safe places are not considered here

Formal Models for Distributed Negotiations5 Zero-Safe Nets with Inhibitor Arcs The combined use of zero-safe places and inhibitor arcs is not completely straightforward We would like to keep consistent refined / abstract views the example above has apparently two independent transactions (s followed by r / just t) they are not really independent because tokens flow in z not reflected in the abstract view Ambiguity solved by restricting inhibitor arcs to stable places only t sr ba cd z

Formal Models for Distributed Negotiations6 Operational Semantics No read arcs on zero safe places (can be relaxed) No inhibitor arcs on zero safe places (avoid ambiguity) (Fix the positive/negative context and do the transaction) if (x  x’)  (u  u’  w  w’  v  v’) =  x  u  x  w  N B v  y x  (u,x)  w  B (v,y) [underlying steps] x  (u,  )  w  B (v,  ) x  u  w  B v [commit] x  (u  w,x)  w  B (v  w,x’) x’  (u’  w,x’)  w  B (v’  w,y)  x  x’  (u  u’  w,x)  w  B (v  v’  w,y) [horizontal composition]

Formal Models for Distributed Negotiations7 From Linda to TraLinda Main ideas: distinguish between low-level and high-level messages Typing relation a:  with  {L,H} atomic prefixing  _C Execute  if the concurrent program C can complete the transaction stable guards only! solve ambiguity in the semantics

Formal Models for Distributed Negotiations8 Syntax Messages M ::=  a:  Action Prefixes  ::= out(a:  ) | rd(a:H) | in(a:  ) | !in(a:  ) Predicates  ::= rdp(a:H) | inp(a:H) Sequential Programs S::= 0 | .C |  ?C:C |  _C Concurrent Programs C ::= S | C|C Processes P ::= M | C | P|P can be relaxed cannot be relaxed

Formal Models for Distributed Negotiations9 Examples in(a:H)_(out(b:H).0 | in(c:H).0) can input the message  a:H  provided that also inputs  c:H  and outputs  b:H  P 1 | … | P n | Q n P i = in(a i :H)_out(z:L).0 Q 0 = Q (generic process) Q i+1 = in(z:L)_Q i can start a task Q after consuming the messages  a 1 :H  …  a n :H  (regardless of the order) in(a:H)_0 deadlock (always abort): should we allow it?

Formal Models for Distributed Negotiations10 Truly Concurrent Semantics for TraLinda Straightforward adaptation of truly concurrent semantics for Linda We must carefully distinguish zero safe places from stable ones Messages  a:H  is stable  a:L  is zero safe Sequential Processes Two versions P is stable _P is zero safe (due to atomic prefixing) Correspondingly, there are two versions of transitions

Formal Models for Distributed Negotiations11 Decomposition Function dec(P) is defined as usual, plus dec(  _P) =  _P In general dec(P) = {P 1,…,P n,M 1,…,M m } We let _dec(P) = {_P 1,…,_P n,M 1,…,M m }

Formal Models for Distributed Negotiations12 Some Transitions See [Bruni, Montanari 2003] for full list and technicalities IN(a, ,P) :    a:   in(a:  ).P  dec(P) ATIN(a, ,P) :    a:   in(a:  )_P  _dec(P) OUT(a, ,P) :   out(a:  ).P   a:   dec(P) ATOUT(a, ,P) :   out(a:  )_P   a:   _dec(P) _IN(a, ,P) :    a:   _in(a:  ).P  dec(P) _ATIN(a, ,P) :    a:   _in(a:  )_P  _dec(P) _OUT(a, ,P) :   _out(a:  ).P   a:   dec(P) _ATOUT(a, ,P) :   _out(a:  )_P   a:   _dec(P)

Formal Models for Distributed Negotiations13 Example: Message Typing out(a:H).Pin(a:H).Q dec(P) … … … dec(Q) …  a:H  out(a:H).P | in(a:H).Q

Formal Models for Distributed Negotiations14 Example: Message Typing out(a:L).P …… in(a:L).Q dec(P) … dec(Q) …  a:L  out(a:L).P | in(a:L).Q

Formal Models for Distributed Negotiations15 Example: Prefixing … in(a:L).out(b:H).P  a:L   b:H  … dec(P) … out(b:H).P

Formal Models for Distributed Negotiations16 Example: Prefixing … in(a:L)_out(b:H).P  a:L   b:H  … dec(P) … _out(b:H).P

Formal Models for Distributed Negotiations17 Example: Prefixing … in(a:L)_out(b:H)_P  a:L   b:H  … _dec(P) … _out(b:H)_P

Formal Models for Distributed Negotiations18 Example: Reading Take the process P = P 1 | P 2 |  a:H  |  b:H  P 1 = rd(a:H)_in(b:H)_out(c:H).0 P 2 = rd(b:H)_in(a:H)_out(c:H).0 Either P 1 or P 2 can be executed successfully, but not both because the messages  a:H  and  b:H  cannot be first read and then consumed during the same transaction Compare against Q = Q 1 | Q 2 |  a:H  |  b:H  Q 1 = rd(a:H).in(b:H).out(c:H).0 Q 2 = rd(b:H).in(a:H).out(c:H).0

Formal Models for Distributed Negotiations19 Example: Reading ……  a:H  … ………  b:H  c:H  0 P1P1 P2P2

Formal Models for Distributed Negotiations20 Some Results For each process P we can construct a finite zero safe net zsnet(P) If P does not contain atomic prefixing The only zero safe places in zsnet(P) are those associated with messages all transactions in zsnet(P) consist of two events at most If P is a Linda process, then zsnet(P)=net(P)

Formal Models for Distributed Negotiations21 A Note on Ordered and Unordered Semantics I Ordered and unordered semantics for Linda have different expressive power (deadlock is decidable in the unordered) In their corresponding net semantics, net O (P) and net U (P), the main difference relies in the atomicity of emission and rendering Take  a  as stable or zero safe We can translate unordered processes in ordered processes via a transformation div(.) div(out(a).P) = out(_a).div(P) | in(_a).out(a).0 div(.) is the identity for the rest

Formal Models for Distributed Negotiations22 A Note on Ordered and Unordered Semantics II Proposition net U (P) is deadlock equivalent to net O (div(P)) (the proof exploits a third net equivalent to both) Atomicity is essential, take div’(out(a).P) = out(_a:L).div’(P) | in(_a:L)_out(a:H).0 div’(.) is the identity for the rest Proposition net O (P) is deadlock equivalent to (the abstract net of) zsnet(div’(P))

Formal Models for Distributed Negotiations23 An Alternative Approach In the context of coordination middlewares JavaSpaces (Sun Microsystem) TSpaces (IBM) Both borrowing features from generative communications of Linda (data-driven coordination) Also event notification (control-driven coordination) Transaction mechanisms Interest on serializability JavaSpaces specifications were not enough precise! [Busi, Zavattaro 2001]

Formal Models for Distributed Negotiations24 Sketch of the Alternative Approach PDL similar to that of Linda New prefixes for transactions create(x) commit(x) New processes  a  T x{P} Interleaving semantics suitable observations Limitations: No nesting, ad-hoc interleaving semantics, monolitic view

Formal Models for Distributed Negotiations25 Principles Data produced within a transaction x will be accessible outside only after the commit of x Data consumption or test for presence within a transaction can operate on local and global items Data tested for presence during a transaction x cannot be consumed by processes outside x Concerning test for absence in a transaction x, if the only occurrences of matching data have been consumed by another transaction, the operation will wait for the commit before reporting the absence of data

Formal Models for Distributed Negotiations26 Improving the Specification “When read, an entry is added to the set of entries read by the provided transaction. Such an entry may be read in any other transaction to which the entry is visible, but cannot be taken” Ok if we do not have conditionals in the language Otherwise, this is not enough for guaranteeing serializability A further lock policy is proposed: “After a test for absence is performed inside a transaction on a certain kind of data, no data of that kind can be introduced in the shared dataspace before the end of the transaction” New processes needed: x{P} R,A to keep track of data removed (R) and tested for absence (A) by x

Formal Models for Distributed Negotiations27 Recap We have seen Transaction primitives for Linda Inspired from zero safe nets Truly concurrent semantics Refined / abstract views Examples Sketch of an alternative approach

Formal Models for Distributed Negotiations28 References Concurrent models for Linda with transactions (Mathematical Structures in Computer Science, 2003, to appear) R. Bruni, U. Montanari On the serializability of transactions in JavaSpaces (Proc. ConCoord’01, ENTCS 54) N. Busi, G. Zavattaro