Open Transactions on Shared Memory
aa r X i v : . [ c s . P L ] M a r Open Transactions on Shared Memory
Marino Miculan Marco Peressotti Andrea Toneguzzo [email protected] [email protected] [email protected]
Laboratory of Models and Applications of Distributed SystemsDepartment of Mathematics and Computer ScienceUniversity of Udine, Italy
Abstract
Transactional memory has arisen as a good way for solving many of the issues of lock-based programming. However, most implementations admit isolated transactions only,which are not adequate when we have to coordinate communicating processes. To thisend, in this paper we present
OCTM , an Haskell-like language with open transactions overshared transactional memory: processes can join transactions at runtime just by accessingto shared variables. Thus a transaction can co-operate with the environment through sharedvariables, but if it is rolled-back, also all its effects on the environment are retracted. Forproving the expressive power of
OCTM we give an implementation of
TCCS m , a CCS-likecalculus with open transactions. Coordination of concurrent programs is notoriously difficult. Traditional fine-grained lock-basedmechanisms are deadlock-prone, inefficient, not composable and not scalable. For these reasons,
Software Transactional Memory (STM) has been proposed as a more effective abstraction forconcurrent programming [1, 9, 18]. The idea is to mark blocks of code as “atomic”; at runtime,these blocks are executed so that the well-known ACID properties are guaranteed. Transactionsensure deadlock freedom, no priority inversion, automatic roll-back on exceptions or timeouts,and greater parallelizability. Among other implementations, we mention
STM Haskell [7], whichallows atomic blocks to be composed into larger ones. STM Haskell adopts an optimistic eval-uation strategy: the blocks are allowed to run concurrently, and eventually if an interference isdetected a transaction is aborted and its effects on the memory are rolled back.However, standard ACID transactions are still inadequate when we have to deal with com-municating processes, i.e., which can exchange information during the transactions. This is verycommon in concurrent distributed programming, like in service-oriented architectures, whereprocesses dynamically combine to form a transaction, and all have to either commit or aborttogether. In this scenario the participants cannot be enclosed in one transaction beforehand,because transactions are formed at runtime. To circumvent this issue, various forms of opentransactions have been proposed, where the Isolation requirement is relaxed [2–4,11,13]. In par-ticular,
TransCCS and
TCCS m are two CCS-like calculi recently introduced to model communi-cating transactions [4, 5, 11]. These calculi offer methodologies for proving important properties,such as fair-testing for proving liveness and bisimulations for proving contextual equivalences.Now, if we try to implement cross-transaction communications a la TCCS m in STM Haskellor similar languages, it turns out that isolated transactions are not expressive enough. As anexample, let us consider two TCCS m transactions hhhhh ¯ c.P ◮ iiiii | hhhhh c.Q ◮ iiiii synchronizing on a1hannel c . Following the standard practice, we could implement this synchronization as twoparallel processes using a pair of semaphores c1,c2 (which are easily realized in STM Haskell): hhhhh ¯ c.P ◮ iiiii = atomic {up c1 -- 1.1down c2 -- 1.2P} hhhhh c.Q ◮ iiiii = atomic {down c1 -- 2.1up c2 -- 2.2Q} This implementation is going to deadlock: the only possible execution order is 1.1-2.1-2.2-1.2,which is possible outside transactions but it is forbidden for ACID transactions . The problem isthat ordinary STM transactions are kept isolated, while in TCCS m they can merge at runtime.In order to address this issue, in this paper we introduce software transactional memorywith open transactions: processes can join transactions and transactions can merge at runtime,when they access to shared variables. To this end, we present OCTM , a higher-order languageextending the concurrency model of STM Haskell with composable open (multi-thread) trans-actions interacting via shared memory . The key step is to separate the isolation aspect fromatomicity: in
OCTM the atomic construct ensures “all-or-nothing” execution, but not isolation;when needed, isolated execution can be guaranteed by a new constructor isolated . An atomic block is a participant (possibly the only one) of a transaction. Notice that transaction mergingis implicitly triggered by accessing to shared memory, without any explicit operation or a priori coordination. For instance, in
OCTM the two transactions of the example above would mergebecoming two participants of the same transaction, hence the two threads can synchronize andproceed. In order to prove formally the expressivity of open memory transactions, we define animplementation of
TCCS m in OCTM , which is proved to correctly preserve behaviours by meansof a suitable notion of simulation. We have based our work on STM Haskell as a paradigmaticexample, but this approach is general and can be applied to other STM implementations.Lesani and Palsberg [13] have proposed transactions communicating through transactionalmessage-based channels called transactional events . These mechanisms are closer to models likeTransCCS and
TCCS m , but on the other hand they induce a strict coupling between processes,which sometimes is neither advisable nor easy to implement (e.g., when we do not know alltransaction’s participants beforehand). In fact, most STM implementations (including STMHaskell) adopt the shared memory model of multi-thread programming; this model is also moreamenable to implementation on modern multi-core hardware architectures with transactionalmemory [8]. For these reasons, in OCTM we have preferred to stick to loosely coupled interactionsbased on shared memory only.The rest of the paper is structured as follows. In Section 2 we describe the syntax andsemantics of
OCTM . Some examples are in Section 3. In Section 4 we assess the expressivenessof
OCTM by providing an implementation of
TCCS m , our reference model for open transactions.Conclusions and directions for future work are in Section 5. Longer proofs are in the Appendix. OCTM : Open Concurrent Transactional Memory
In this section we introduce the syntax and semantics of
OCTM , a higher-order functional lan-guage with threads and open transaction on shared memory. The syntax is Haskell-like (in thewake of existing works on software transactional memories such as [7]) and the semantics is asmall-step operational semantics given by two relations: β −→ models transaction auxiliary opera- This possibility was pointed out also in [7]: “two threads can easily deadlock if each awaits some communi-cation from the other”. V ::= r | λx.M | return M | M >>= N | newVar M | readVar r | writeVar r M | fork M | atomic M N | isolated M | abort M | retry Term
M, N ::= x | V | M N | . . . Figure 1: Syntax of
OCTM values and terms.tions (e.g. creation) while −→ models actual term evaluations. Executions proceeds by repeatedlychoosing a thread and executing a single (optionally transactional) operation; transitions fromdifferent threads may be arbitrarily interleaved as long as atomicity and isolation are not violatedwhere imposed by the program. The syntax can be found in Figure 1 where the meta-variables r and x range over a givencountable set of locations Loc and variables
Var respectively. Terms and values are inspired toHaskell and are entirely conventional ; they include abstractions, application, monadic operators( return and >>= ), memory operators ( newVar , readVar , writeVar ), forks, transactionalexecution modalities ( atomic and isolated ) and transaction operators ( abort and retry ).Effectfull expressions such as fork or isolated are glued together by the (overloaded)monadic bind >>= e.g.: newVar 0 >>= λx. (fork (writeVar x
42) >>= λy. readVar x ) whereas values are “passed on” by the monadic unit return .Akin to Haskell, we will use underscores in place of unused variables (e.g. λ . ) and M >> N as a shorthand for M >>= λ .N , and the convenient do -notation : do { x ← M ; N } ≡ M >>= ( λx. do { N } ) do { M ; N } ≡ M >>= ( λ . do { N } ) do { M } ≡ M possibly trading semicolons and brackets for the conventional Haskell layout . For instance, theabove example is rendered as do x ← newVar 0fork (writeVar x x We present the operational semantics of
OCTM in terms of an abstract machine whose statesare triples h P ; Θ , ∆ i formed by • thread family (process) P ; • heap memory Θ : Loc ⇀ Term ; • distributed working memory ∆ : Loc ⇀ Term × TrName where
Term denotes the set of
OCTM terms (cf. Figure 1) and
TrName denotes the set of namesused by the machine to identify active transactions.We shall denote the set of all possible states as
State . We treat the application of monadic combinators (e.g. return ) as values in the line of similar works [7]. hreads Threads are the smaller unit of execution the machine scheduler operates on; theyexecute OCTM terms and do not have any private transactional memory.Threads are given unique identifiers (ranged over by t or variations thereof) and, wheneverthey take part to some transaction, the transaction identifier (ranged over k, j or variationsthereof). Threads of the former case are represented by ([ M ]) t where M is the term beingevaluated and the subscript t is the thread identifier. Threads of the latter case have two forms:([ M ⊲ M ′ ; N ]) t,k , called and ([ M ⊲ M ′ ]) t,k where: • M is the term being evaluated inside the transaction k ; • M ′ is the term being evaluated as compensation in case k is aborted; • N is the term being evaluated as continuation after k commits or aborts.Threads with a continuation are called primary participants (to transaction k ) , while threadswithout continuation are the secondary participants . The former group includes all and only thethreads that started a transaction (i.e. those evaluated in an atomic ), while the latter groupencompasses threads forked inside a transaction and threads forced to join a transaction (fromoutside a transactional context) because of memory interactions. While threads of both groupscan force a transaction to abort or restart, only primary participants can vote for its commitand hence pass the transaction result to the continuation.We shall present thread families using the evocative CCS-like parallel operator k (cf. Figure 2)which is commutative and associative. Notice that this operator is well-defined only on operandswhose thread identifiers are distinct. The notation is extended to thread families with denotingthe empty family. Memory
The memory is divided in the heap Θ and in a distributed working memory ∆. Asfor traditional closed (acid) transactions (e.g. [7]), operations inside a transaction are evaluatedagainst ∆ and effects are propagated to Θ only on commits. When a thread inside a transaction k accesses a location outside ∆ the location is claimed for k and remains claimed for the restof k execution. Threads inside a transaction can interact only with locations claimed by theirtransaction. To this end, threads outside any transaction can join an existing one and differentactive transactions can be merged to share their claimed locations.We shall denote the pair h Θ , ∆ i by Σ and reference to each projected component by a sub-script e.g. Σ Θ for the heap. When describing updates to the state Σ, we adopt the conventionthat Σ ′ has to be intended as equal to Σ except if stated otherwise, i.e. by statements likeΣ ′ Θ = Σ Θ [ r M ].Formally, updates to location content are defined on Θ and ∆ as follows:Θ[ r M ]( s ) , ( M if r = s Θ( s ) otherwise ∆[ r ( M, k )]( s ) , ( ( M, k ) if r = s ∆( s ) otherwisefor any r, s ∈ Loc , M ∈ Term and k ∈ TrName . Likewise, updates on transaction names aredefined on Σ and ∆ as follows:Σ[ k j ] , (Θ , ∆[ k j ]) (∆[ k j ])( r ) , ( ∆( r ) if ∆( r ) = ( M, l ) , l = k ( M, j ) if ∆( r ) = ( M, k )for any r ∈ Loc , M ∈ Term and k, j ∈ TrName . Note that j may occur in ∆ resulting in thefusion of the transactions denoted by k and j respectively. Finally, ∅ denotes the empty memory(i.e. the completely undefined partial function).4hread T t ::= ([ M ]) t | ([ M ⊲ M ′ ; N ]) t,k | ([ M ⊲ M ′ ]) t,k Thread family P ::= T t k · · · k T t n ∀ i, j t i = t j Expressions E ::= [ − ] | E >>= M Processes P t ::= ([ E ]) t Transactions T t,k ::= ([ E ⊲ M ; N ]) t,k | ([ E ⊲ M ]) t,k Figure 2: Threads and evaluation contexts. M V V [ M ] = VM → V ( Eval ) return M >>= N → N M ( BindReturn ) retry >>= M → retry ( BindRetry ) abort N >>= M → abort N ( BindAbort ) Figure 3:
OCTM semantics: rules for term evaluation.
Behaviour
Evaluation contexts are shown in Figure 2 and the transition relations are presentedin Figures 3, 4, 5. The first (cf. Figures 3) is defined on terms only and models pure computations.In particular, rule (
Eval ) allows a term M that is not a value to be evaluated by an auxiliary(partial) function, V [ M ] yielding the value V of M whereas the other three rules define thesemantic of the monadic bind. The transition relation modelling pure computations can bethought as accessory to the remaining two for these model transitions between the states of themachine under definition.Derivation rules in Figure 4 characterize the execution of pure (effect-free) terms, forks andmemory operations both inside, and outside of some transaction; Derivation rules in Figure 5characterize auxiliary operations for transaction management (e.g. creation) and their coordina-tion (e.g distributed commits). Note that there are no derivation rules for retry . In fact, themeaning of retry is to inform the machine that choices made by the scheduler led to a statefrom which the program cannot proceed. From an implementation perspective this translatesin the transaction being re-executed from the beginning (or a suitable check-point) following adifferent scheduling of its operations.We shall describe now a representative subset of the derivation rules from Figures 4 and 5.Reading a location falls into four cases depending on the location being claimed (i.e. occurringin ∆) and the reader being part of a transaction. The rule ( ReadP ) characterize the reading ofan unclaimed location from outside any transaction; the read is performed as expected leavingit unclaimed. Rule (
ReadT ) describes the reading of an unclaimed location r by a threadbelonging to some transaction k ; the side effect of the reading is r being claimed for k . Rules( ReadMerge ) and (
ReadJoin ) cover the cases of readings against claimed locations. In thefirst scenario, the reading thread belongs to a transaction resulting in the two being merged,which is expressed by renaming its transaction via a substitution. In the remaining scenario,the reading thread does not belong to any transaction and hence joins the transaction k whichclaimed the location. The newly created participant does not have any continuation since thewhole term is set to be executed inside k ; any other choice for splitting the term singling outa compensation would impose an artificial synchronization with the transaction commit. For acounter example, consider executing only the read operation inside the transaction and delayingeverything after the commit; then concurrency will be clearly reduced. Because of the samereasoning, the whole term M is taken as the compensation of the participant.Transactions are created by rule ( Atomic ); threads participating in a transaction are non-deterministically interleaved with other threads. The stronger requirement of isolation is offered5 → N h P t [ M ] k P ; Σ i −→ h P t [ N ] k P ; Σ i ( TermP ) M → N h T t,k [ M ] k P ; Σ i −→ h T t,k [ N ] k P ; Σ i ( TermT ) t ′ / ∈ threads ( P ) t = t ′ h P t [ fork M ] k P ; Σ i −→ h P t [ return t ′ ] k ([ M ]) t ′ k P ; Σ i ( ForkP ) t ′ / ∈ threads ( P ) t = t ′ h T t,k [ fork M ] k P ; Σ i −→ h T t,k [ return t ′ ] k ([ M ⊲ return ]) t ′ ,k k P ; Σ i ( ForkT ) threads ( T t k · · · k T t n ) , { t , . . . , t n } r / ∈ dom(Σ Θ ) ∪ dom(Σ ∆ ) Σ ′ Θ = Σ Θ [ r M ] h P t [ newVar M ] k P ; Σ i −→ h P t [ return r ] k P ; Σ ′ i ( NewP ) r / ∈ dom(Σ Θ ) ∪ dom(Σ ∆ ) Σ ′ ∆ = Σ ∆ [ r ( M, k )] h T t,k [ newVar M ] k P ; Σ i −→ h T t,k [ return r ] k P ; Σ ′ i ( NewT ) r / ∈ dom(Σ ∆ ) Σ Θ ( r ) = M h P t [ readVar r ] k P ; Σ i −→ h P t [ return M ] k P ; Σ i ( ReadP ) r / ∈ dom(Σ ∆ ) Σ Θ ( r ) = M Σ ′ ∆ = Σ ∆ [ r ( M, k )] h T t,k [ readVar r ] k P ; Σ i −→ h T t,k [ return M ] k P ; Σ ′ i ( ReadT ) M = E [ readVar r ] Σ ∆ ( r ) = ( M ′ , k ) h ([ M ]) t k P ; Σ i −→ h ([ E [ return M ′ ] ⊲ λ . M ]) t,k k P ; Σ i ( ReadJoin ) Σ ∆ ( r ) = ( M, j ) Σ ′ = Σ[ k j ] h T t,k [ readVar r ] k P ; Σ i −→ h T t,j [ return M ] k P [ k j ]; Σ ′ i ( ReadMerge ) r / ∈ dom(Σ ∆ ) Σ Θ ( r ) = N Σ ′ Θ = Σ Θ [ r M ] h P t [ writeVar r M ] k P ; Σ i −→ h P t [ return () ] k P ; Σ ′ i ( WriteP ) r / ∈ dom(Σ ∆ ) Σ Θ ( r ) = N Σ ′ ∆ = Σ ∆ [ r ( M, k )] h T t,k [ writeVar r M ] k P ; Σ i −→ h T t,k [ return () ] k P ; Σ ′ i ( WriteT ) M = E [ writeVar r M ′ ] Σ ∆ ( r ) = ( M ′′ , k ) Σ ′ ∆ = Σ ∆ [ r ( M ′ , k )] h ([ M ]) t k P ; Σ i −→ h ([ E [ return () ] ⊲ λ .M ]) t,k k P ; Σ ′ i ( WriteJoin ) Σ ∆ ( r ) = ( N, j ) Σ ′ = Σ[ k j ] Σ ′ ∆ = Σ ∆ [ k ( M, j )] h T t,k [ writeVar r M ] k P ; Σ i −→ h T t,j [ return () ] k P [ k j ]; Σ ′ i ( WriteMerge ) Figure 4:
OCTM semantics: rules for −→ .by rules ( IsolatedP ) and (
IsolatedT ), whose premises forbid thread or transaction creation.Committing or aborting a transaction require a synchronization of its participants. Inparticular, an abort can be read as a participant vetoing the outcome of the transaction;this corresponds to (
RaiseAbort1 ) and (
RaiseAbort2 ). The information is then propa-gated by (
AbBroadcast ) and (
TrIgnore ) to any other participant to the transaction beingaborted; these participants abort performing a transition described by either (
SigAbort1 ) or(
SigAbort2 ). In this section we provide some short examples to illustrate the use of
OCTM and how standardSTM behaviour can be recovered in
OCTM thanks to the isolated construct. In Section 4.2we will give an extended example by providing a translation of
TCCS m into OCTM .6 / ∈ transactions ( P ) h ([ atomic M N >>= N ′ ]) t k P ; Σ i new k −−−→ h ([ M ⊲ N ; N ′ ]) t,k k P ; Σ i ( Atomic ) h ([ M ]) t ; Σ i → ∗ h ([ return N ]) t ; Σ ′ ih P t [ isolated M ]; Σ i → h P t [ return N ]; Σ ′ i ( IsolatedP ) op ∈ { abort , return } h ([ M ⊲ return ]) t,k ; Σ i → ∗ h ([ op N ⊲ return ]) t,k ; Σ ′ ih T t,k [ isolated M ]; Σ i → h T t,k [ op N ]; Σ ′ i ( IsolatedT ) Σ ′ ∆ = clean ( k, Σ ∆ ) h ([ abort M ⊲ N ; N ′ ]) t,k ; Σ i ab k M −−−−→ h ([ N ( M ) >>= N ′ ]) t ; Σ ′ i ( RaiseAbort1 ) Σ ′ ∆ = clean ( k, Σ ∆ ) h ([ abort M ⊲ N ]) t,k ; Σ i ab k M −−−−→ h ([ N ( M )]) t ; Σ ′ i ( RaiseAbort2 ) Σ ′ ∆ = clean ( k, Σ ∆ ) h ([ M ⊲ N ; N ′ ]) t,k ; Σ i b ab k M −−−−→ h ([ N ( M ) >>= N ′ ]) t ; Σ ′ i ( SigAbort1 ) Σ ′ ∆ = clean ( k, Σ ∆ ) h ([ M ⊲ N ]) t,k ; Σ i b ab k M −−−−→ h ([ N ( M )]) t ; Σ ′ i ( SigAbort2 ) h P ; Σ i ab k M −−−−→ h P ′ ; Σ ′ i h Q ; Σ i b ab k M −−−−→ h Q ′ ; Σ ′ ih P k Q ; Σ i ab k M −−−−→ h P ′ k Q ′ ; Σ ′ i ( AbBroadcast ) Σ ′ Θ = commit ( k, Σ Θ , Σ ∆ ) Σ ′ ∆ = clean ( k, Σ ∆ ) h ([ return M ⊲ N ; N ′ ]) t,k ; Σ i co k −−→ h ([ return M >>= N ′ ]) t ; Σ ′ i ( Commit1 ) Σ ′ Θ = commit ( k, Σ Θ , Σ ∆ ) Σ ′ ∆ = clean ( k, Σ ∆ ) h ([ M ⊲ N ]) t,k ; Σ i co k −−→ h ([ M ]) t ; Σ ′ i ( Commit2 ) h P ; Σ i co k −−→ h P ′ ; Σ ′ i h Q ; Σ i co k −−→ h Q ′ ; Σ ′ ih P k Q ; Σ i co k −−→ h P ′ k Q ′ ; Σ ′ i ( CoBroadcast ) h P ; Σ i β −→ h P ′ ; Σ ′ i transactions ( β ) / ∈ transactions ( Q ) h P k Q ; Σ i β −→ h P ′ k Q ; Σ i ( TrIgnore ) clean ( k, ∆)( r ) , ( ⊥ if ∆( r ) = ( M, k )∆( r ) otherwise commit ( k, Θ , ∆)( r ) , ( M if ∆( r ) = ( M, k )Θ( r ) otherwise transactions (([ M ]) t ) , ∅ transactions (([ M ⊲ M ′ ; N ]) t,k ) , { k } transactions (([ M ⊲ N ]) t,k ) , { k } transactions ( T t k · · · k T t n ) , [ ≤ i ≤ n transactions ( T t i )Figure 5: OCTM semantics: rules for β −→ . One of the basic constructs offered by Concurrent Haskell are
MVars [10] i.e. mutable locationsthat are either empty or contain a value of the given type parameter. Interaction with thesestructures is based on two fundamental operations: putMVar which fills an
MVar if it is emptyand blocks otherwise, and takeMVar which empties an
MVar if it is full and blocks otherwise.In [7]
MVar s are implemented on top of
TVar s (i.e. STM Haskell transactional locations).7ollowing [7] an
MVar of type a is implemented on top of a OTVar (our transactional locationsi.e. any r ∈ Loc ) holding a value of type
Maybe a ; this is a type that is either an empty value(
Nothing ) or actually holds a value of type a (e.g. Just 42 ). Thus, the definition of the type
MVar a is the following: type MVar a = OTVar (Maybe a) and its two constructors for creating an empty and a full location are: newEmptyMVar = newVar NothingnewMVar x = newVar (Just x ) The definition of the two basic operations is precisely the same appearing in [7] except for theadded isolated construct for enforcing isolation. takeMVar v = isolated do v ← readVar v case v ofNothing → retryJust x → dowriteVar x Nothingreturn x putMVar v y = isolated do v ← readVar v case v ofNothing → writeVar y NothingJust → retry MVar s can be used as simple directional channels with takeMVar and putMVar as receive andsend. Then a bidirectional channel for a remote procedure call is easily implemented using a pairof
MVar s type RPC a b = (MVar (CorId, a), MVar (CorId, b)) where a and b are the types of the request and response exchanged and CorId is a suitable typeproviding a correlation identifier for relating a request to its response.Before we introduce the skeleton and stub let us define a conditional variation of the takeMVar accepting a boolean predicate p and such that it empties the given MVar v only if the containedvalue satisfies p and blocks (issue a retry ) otherwise. takeMVarIf p v = isolated do v ← readVar v case v ofNothing → retryJust x → doif p x thenwriteVar x Nothing >> return x elseretry The conditional version of takeMVar allows us to take a response only if we know its correlationidentifier and hence the call is simply: rpcCall ( req , res ) data = do c ← newCorrelationIdputMVar req ( c , data ) r ← takeMVarIf ( c == fst) res return (snd r ) fst and snd are the first and second projections respectively. Symmetrically, to providethe rpc we just need to take a request from the MVar req and put its response in res using thesame correlation identifier: rpcServe ( req , res ) data = do q ← takeMVar reqa ← doSomething (snd q )putMVar res (fst q , a ) If any of the two parties happens to be partaking a transaction the rpc results in the other joiningthe transaction effectively rendering the rpc transactional.The above example is quite simplified (e.g. requests could have been handled by a buffer, andthe structure of ( req , req ) should be hidden to the user) but serves the purpose of illustratingthe difference between OCTM and STM. handled by a buffer, and the structure of ( req , req ) should be hidden to the user) but serves the purpose of illustrating the difference between OCTM and STM. In fact, the above implementation allows the call to happen inside a transactionwithout resulting into a lock as in the case of STM since isolation will prevent the serving threadto join and provide a response.
OCTM
In order to assess the expressive power of
OCTM , in this Section we prove that it can be usedto implement
TCCS m , a formal model for open transactions [11]. We proceed as follow: first, inSubsection 4.1 we recall TCCS m ; then, the translation of TCCS m processes into OCTM statesis defined in Subsection 4.2; this translation is proved to be correct in Subsection 4.3.
TCCS m : CCS with open transactions TCCS m [11] is a CCS-like calculus with open flat can synchronize even when belonging todifferent transactions, which in turn are joined into a distributed one. We refer to [11] for adetailed description of TCCS m . transactions: processes can synchronize even when belongingto different transactions, which in turn are joined into a distributed one. We refer to [11] for adetailed description of TCCS m .The syntax of TCCS m is defined by the following grammar P ::= P ni =1 α i .P i | Q mi =0 P i | P \ L | X | µX.P | hhhhh P ◮ P iiiii | hh P ⊲ k P ii | co .P (1)where α i ::= a | ¯ a | τ , a ranges over a given set of visible actions A , L over subsets of A and thebijection ( · ) : A → A maps every action to its coaction as usual. The calculus extends CCS withthree constructs which represent inactive transactions, active transactions and commit actionsrespectively. Transactions such as hh P ⊲ k P ii are formed by two processes with the former beingexecuted atomically and the latter being executed whenever the transaction is aborted, i.e. asa compensation . Terms denoting active transactions expose also a name ( k in the previous ex-ample) which is used to track transaction fusions. For instance, consider the process denotedby hh P ⊲ j P ii | hh Q ⊲ k Q ii where P and Q synchronize on some a ∈ A ; the result of thissynchronization is the fusion of the transactions j and k i.e. hh P ′ ⊲ l P ii | hh Q ′ ⊲ l Q ii . The fusionmakes explicit the dependency between j and k introduced by the synchronization and ties themto agree on commits. In this sense, P ′ and Q ′ are participants of a distributed transaction [6].As in [11] we restrict ourselves to well-formed terms. Intuitively, a term is well-formed if activetransactions occur only at the top-level and commit actions occur only in a transaction (active9 ⊢ P : p ς ⊢ P : τ ς ⊢ P : p ς ⊢ co .P : c ς ⊢ P : τς ⊢ P \ L : τς ⊢ X : ς ( X ) ς [ X : p ] ⊢ P : p ς ⊢ µX.P : p ς [ X : c ] ⊢ P : c ς ⊢ µX.P : c ∀ i ς ⊢ P i : τς ⊢ Q P i : τ ∀ i ς ⊢ P i : p ς ⊢ P α i .P i : p ∀ i ς ⊢ α i .P i : c ς ⊢ P α i .P i : c ς ⊢ P : c ς ⊢ Q : p ς ⊢ hh P ⊲ k Q ii : t ς ⊢ P : c ς ⊢ Q : p ς ⊢ hhhhh P ◮ Q iiiii : p Figure 6: Simple types for
TCCS m .or inactive). To this end we introduce a type system for TCCS m , whose rules are in Figure 6.Terms that cannot occur inside a transaction have type t , terms that cannot occur outside atransaction have type c , and terms without such restrictions have type p ; τ ranges over types. Definition 1 (Well-formed
TCCS m terms) . A TCCS m term P , described by the grammar in (1) , is said to be well-formed if, and only if, ∅ ⊢ P : t . Well-formed terms form the set Proc . The operational semantics of well-formed
TCCS m terms is given by the SOS in Figure 7(see [11] for further details). The reduction semantics is given as a binary relation → defined by P → Q △ ⇐⇒ P τ −→ σ Q ∨ P β −→ Q ∨ P k ( τ ) −−−→ σ Q .The first case is a synchronization between pure CCS processes. The second case correspondsto creation of new transactions and distributed commit or abort ( β ∈ { new k, co k, ab k } ). Thethird case corresponds to synchronizations of processes inside a named (and possibly distributed)transaction. Notice that by ( TSync ) transaction fusion is driven by communication and thatby (
TSum ) any pure CCS process can join and interact with a transaction.
TCCS m in OCTM
In this section we define the translation from
TCCS m processes to OCTM states. To this end,we have to implement transactions and CCS-like synchronizations using shared transactionalvariables and the atomic and isolated operators.Synchronization is implemented by means of shared transactional variables, one for eachchannel, that take values of type
ChState (cf. Figure 9); this type has four constructors: onefor each of the three messages of the communication protocol below plus a “nothing” one pro-viding the default value. Let t and t be the identifiers of two threads simulating a.P and a.Q respectively. The protocol is composed by the following four steps:1. t checks whether the channel is free and writes on the transactional variable modellingthe channel a a nonce tagged with the constructor M1 ;2. t reads the variable for a and accepts the synchronization offered by the challenge (M1np) adding a fresh nonce to it and writing back (M2 np nq) ;3. t reads the answer to its challenge and acknowledges the synchronization writing back thenonce it read tagged with the constructor M3 ;4. t reads the acknowledgement and frees the channel.10 α i .P i α i −→ ε P i ( Sum ) P a −→ ε P ′ Q ¯ a −→ ε Q ′ P | Q τ −→ ε P ′ | Q ′ ( Sync ) µX.P τ −→ ε P [ µX.P / X ] ( Rec ) P α −→ σ P ′ img ( σ ) ∩ tn ( Q ) = ∅ P | Q α −→ σ P ′ | Q [ σ ] ( ParL ) τ = α j P α i .P i k ( α j ) −−−→ ε k hh P j | co ⊲ k P α i .P i ii ( TSum ) P α −→ ε P ′ τ = α l = k hh P ⊲ l Q ii k ( α ) −−−→ l k hh P ′ ⊲ k Q ii ( TAct ) P k ( a ) −−−→ i k P ′ Q k (¯ a ) −−−→ j k Q ′ P | Q k ( τ ) −−−→ i,j k P ′ [ j k ] | Q ′ [ i k ] ( TSync ) P α −→ σ P ′ α / ∈ LP \ L α −→ σ P ′ \ L ( Res ) P τ −→ ε P ′ hh P ⊲ k Q ii τ −→ ε hh P ′ ⊲ k Q ii ( TTau ) hh P ⊲ k Q ii ab k −−→ Q ( TAb ) P β −→ P ′ P \ L β −→ P ′ \ L ( TRes ) k fresh hhhhh P ◮ Q iiiii new k −−−→ hh P ⊲ k Q ii ( TNew ) ∃ i P i = co .P ′ i hh Q P i ⊲ k Q ii co k −−→ Ψ id ( P ) ( TCo ) P β −→ P ′ Q β −→ Q ′ β = new kP | Q β −→ P ′ | Q ′ ( TB1 ) P β −→ P ′ tn ( β ) / ∈ tn ( Q ) P | Q β −→ P ′ | Q ( TB2 ) Ψ σ ( P ) , Q if P = co .Q Ψ σ ( Q ) \ L if P = Q \ L P α i . Ψ σ ( P i ) if P = P α i .P i Q Ψ σ ( P i ) if P = Q P i µX. Ψ σ [ P / X ] ( Q ) if P = µX.QP [ σ ] otherwise tn ( P ) , { k } if P = hh P ⊲ k Q ii S tn ( P i ) if P = Q P i ∅ otherwise tn ( β ) , k if β = new kk if β = ab kk if β = co k Figure 7:
TCCS m operational semantics.Each step has to be executed in isolation with respect to the interactions with the sharedtransactional variable a .Nonces are meant to correlate the steps only and hence can be easily implemented in OCTM by pairing thread identifiers with counter a la logical clock. If at any step a thread finds thechannel in an unexpected state it means that the chosen scheduling has led to a state incoherentwith respect to the above protocol; hence the thread executes a retry . This tells the schedulerto try another execution order; by fairness, we eventually find a scheduling such that the twoprocesses do synchronize on a and these are the only executions leading to P | Q . The protocolis illustrated in Figure 8. If the synchronizing parties are involved in distinct transactions theseare fused as a side effect of the interaction via the shared variable.A choice like P mi =1 α i .P i can be seen as a race of threads t , . . . , t m , each simulating a branch,to acquire a boolean transactional variable l (private to the group). Each t i proceeds as follows.First, it checks l and if it is set, it returns void and terminates (another thread has alreadyacquired it); otherwise it tries to set it while carrying out α i , i.e. right before executing its laststep of the communication protocol. If the variable is acquired by another thread while t i isfinalizing α i then t i issues a retry to retract any effect of α i . The OCTM code implementingthis protocol is shown in Figure 9. 11 .P a.Q var a M0(M1 np ) (M1 nx )(M2 nx nq )(M2 np ny )(M3 ny ) (M3 nq )M0 TCCS m synchronization. Encoding of
TCCS m We can now define the encoding η : Proc → State , mapping well-formed
TCCS m terms to states of the OCTM abstract machine. Intuitively, a process P ≡ Q mi =1 P i ismapped into a state with a thread for each P i and a variable for each channel in P . Clearly astate of this form can be generated by a single OCTM term which allocates all variables andforks the m threads; we have preferred to map TCCS m terms to OCTM states instead of
OCTM term for sake of simplicity.The map η is defined by recursion along the derivation of ∅ ⊢ P : t and the number m ofparallel components in P ≡ Q mi =1 P i . This is handled by the auxiliary encoding ς : Proc × Heap → State (up to choice of fresh names) whose second argument is used to track memory allocations.The base case is given by m = 0 and yields a state with no threads i.e. h , Θ , ∅ i . The recursivestep is divided in three subcases depending on the structure and type of P ( m > ∅ ⊢ P : c without top-level restrictions (i.e. for no Q and no L = { a , . . . , a n +1 } suchthat each a i occurs in Q the process P is structurally equivalent to Q \ L ) then ς ( Q m +1 i =1 P i , Θ) , h ([ ̺ ( P )]) t k S ; Σ i where h S ; Σ i = ς ( Q m − j =1 P j +1 , Θ) is the translation of the rest of P and t is unique w.r.t. S (i.e. t / ∈ threads ( S )). By hypothesis P does not contain any top-level active transactionor parallel composition and hence can be translated directly into a OCTM -termby means of the encoding ̺ (cf. Figure 10) – ̺ ( P ) contain a free variable for each unre-stricted channel occurring in P .2. If P has a top-level restriction (i.e. P ≡ Q \ { a , . . . , a n +1 } ) then ς ( Q m +1 i =1 P i , Θ) , h S [ r /a , . . . r n +1 /a n +1 ] k S ; Θ [ r , . . . , r n +1 M0 ] , ∅ i where h S ; Θ , ∅ i = ς ( Q, Θ) and h S ; Θ , ∅ i = ς ( Q m − j =1 P j +1 , Θ ) are the translation of theunrestricted process Q and the translation of the rest of P respectively, all threads have aunique identifier threads ( S ) ∩ threads ( S ) = ∅ , the heap is extended with n channel vari-ables fresh ( r , . . . , r n +1 / ∈ dom(Θ )) and known only to the translation of Q .3. If P ≡ hh Q ⊲ k Q ii is an active transaction then ς ( Q m +1 i =1 P i , Θ) , h S co k S ab k S [ r co /co ] k S ; Θ [ r l T rue, r co M0 ] , ∅ i S co = ([ recv r l r co ⊲ ̺ ( Q ); bang (recv (newVar True) r co ) ]) t co ,k S ab = ([ abort () ⊲ return ]) t ab ,k ata Channel = OTVar ChStatedata ChState = M1 Nonce | M2 Nonce Nonce | M3 Nonce | M0tau l P = isolated docase (readVar l ) ofFalse → return ()True → chooseThis l >> P chooseThis l = writeVar l FalseeqOrRetry x y | x == y = return ()| otherwise = retrybang x = fork x >> bang x recv c l P = do nq ← newNonceisolated docase (readVar l) ofFalse → return ()True → dochooseThis l case (readVar c ) of(M1 nx ) → writeVar c (M2 nx nq )_ → retryisolated docase (readVar c ) of(M3 ny ) → eqOrRetry ny nq >> writeVar c M0 >> P _ → retrysend c l P = do np ← newNonceisolated docase (readVar l ) ofFalse → return ()True → dochooseThis l case (readVar c ) ofM0 → writeVar c (M1 np )_ → retryisolated docase (readVar c ) of(M2 nx ny ) → eqOrRetry nx np >> writeVar c (M3 ny ) >> P _ → retry Figure 9: Encoding channels and communication13 ( P mi =1 α i P i ) , do l ← newVar True ∀ i ∈ { , . . . , m } fork ξ ( α i , l , P i ) ̺ ( Q mi =0 P i ) , do ∀ i ∈ { , . . . , m } fork ̺ ( P i ) ̺ ( P \ L ) , do ∀ c ∈ Lc ← newVar M0 ̺ ( P ) ̺ ( X ) , X̺ ( P ) ̺ ( co .P ) , do l ← newVar Truesend co l ̺ ( P ) ̺ ( µX.P ) , let X = ̺ ( P ) in ̺ ( hhhhh P ◮ Q iiiii ) , do co ← newVar M0atomic p ̺ ( Q ) bang psiwherep = do ̺ ( P ) fork (abort ())psipsi = do l ← newVar Truerecv co l return ξ ( α i , l, P i ) , recv α i l ̺ ( P i ) if α i = c send α i l ̺ ( P i ) if α i = c tau l ̺ ( P i ) if α i = τ Figure 10: Encoding
TCCS m terms of type c where h S ; Θ , ∅ i = ς ( Q , Θ), h S ; Θ , ∅ i = ς ( Q m − j =1 P j +1 , Θ ) (like above), the thread S ab is always ready to abort k as in ( TAb ) and S co awaits on the private channel r co a threadfrom S to reach a commit and, after its commit, collects all remaining synchronizationson r co to emulate the effect of Ψ (cf. Figure 7). Finally, all threads have to be uniquelyidentified: threads ( S ) ∩ threads ( S ) = ∅ and t co , t ab / ∈ threads ( S ) ∪ threads ( S ) Remark 1.
The third case of the definition above can be made more precise (at the cost of alonger definition) since the number of commits to be collected can be inferred from Q mimick-ing the definition of Ψ . This solution reduces the presence of dangling auxiliary processes andtransaction fusions introduced by the cleaning process. Like ̺ , ς ( P, Θ) contains a free variable for each unrestricted channel in P . Finally, theencoding η is defined on each P ∈ Proc as: η ( P ) , h S [ r /a , . . . r n /a n ]; Θ[ r , . . . , r n M0 ] , ∅ i where h S ; Θ , ∅ i = ς ( P, ∅ ), { r , . . . , r n } ⊆ Loc , and { a , . . . , a n } ⊆ A is the set of channelsoccurring in P . In this section we prove that the translation η is adequate, in the sense that it preserves theobservational behaviour of TCCS m processes. More precisely, akin to [12], we define an appro-priate notion of star simulation S between well-formed TCCS m processes and states of OCTM .The basic idea is that a single step of P is simulated by a sequence of reductions of η ( P ), and η ( P ) does not exhibit behaviours which are not exhibited by P .14 efinition 2 (Star simulation) . A relation
S ⊆
Proc × State is a star simulation if for all ( P, h S ; Σ i ) ∈ S :1. for all Q such that P τ −→ σ Q or P k ( τ ) −−−→ σ Q , there exist S ′ , Σ ′ such that h S ; Σ i → ∗ h S ′ ; Σ ′ i and ( Q, h S ′ ; Σ ′ i ) ∈ S ;2. for all Q such that P β −→ Q , there exist S ′ , Σ ′ s.t. h S ; Σ i β −→ ∗ h S ′ ; Σ ′ i and ( Q, h S ′ ; Σ ′ i ) ∈ S .3. for all S ′ , Σ ′ such that h S ; Σ i → h S ′ ; Σ ′ i , there exist Q, S ′′ , Σ ′′ such that ( Q, h S ′′ ; Σ ′′ i ) ∈ S and one of the following holds: • P τ −→ σ Q or P k ( τ ) −−−→ σ Q , and h S ′ ; Σ ′ i → ∗ h S ′′ ; Σ ′′ i• P β −→ ǫ Q and h S ′ ; Σ ′ i β −→ ∗ h S ′′ ; Σ ′′ i .where β -labels of the two transition relations are considered equivalent whenever are both commitsor both aborts for the same transaction name. We say that P is star-simulated by h S ; Σ i if thereexists a star-simulation S such that ( P, h S ; Σ i ) ∈ S . We denote by ∗ ≈ the largest star simulation. Another technical issue is that two equivalent
TCCS m processes can be translated to OCTM states which differ only on non-observable aspects, like name renamings, terminated threads, etc.To this end, we need to consider
OCTM states up-to an equivalence relation ∼ = t ⊆ State × State ,which we define next.
Definition 3.
Two OCTM states are transaction-equivalent , written h S ; Σ i ∼ = t h S ; Σ i , whenthey are equal up to: • renaming of transaction and thread names; • terminated threads, i.e. threads of one of the following forms: ([ return M ]) t , ([ abort M ]) t , ([ return ⊲ return ]) t,k , ([ abort ⊲ return ]) t,k , ([ psi ]) t ; • threads blocked in synchronizations on co variables. Definition 4.
Let P ∈ P roc be a well-formed process and h S ; Σ i be a state. P is star simulatedby h S ; Σ i up to ∼ = t if ( P, h S ; Σ i ) ∈ ∗ ≈ ◦ ∼ = t . We are now ready to state our main adequacy result, which is a direct consequence of thetwo next technical lemmata.
Lemma 1.
For all
P, Q ∈ P roc the following hold true:1. if P τ −→ σ Q or P k ( τ ) −−−→ σ Q , there exist S, Σ such that η ( P ) → ∗ h S ; Σ i and h S ; Σ i ∼ = t η ( Q ) ;2. if P β −→ Q , there exist S, Σ such that η ( P ) β −→ ∗ h S ; Σ i and h S ; Σ i ∼ = t η ( Q ) .Proof. See Appendix A.
Lemma 2.
For P ∈ P roc , for all S, Σ , if η ( P ) → h S ; Σ i then there exist Q, S ′ , Σ ′ such that h S ′ ; Σ ′ i ∼ = t η ( Q ) and one of the following holds: • P τ −→ σ Q or P k ( τ ) −−−→ σ Q , and h S ; Σ i → ∗ h S ′ ; Σ ′ i ; • P β −→ ǫ Q and h S ; Σ i β −→ ∗ h S ′ ; Σ ′ i .Proof. See Appendix A.
Theorem 3.
For all P ∈ P roc , P is star simulated by η ( P ) up to ∼ = t . Conclusions and future work
In this paper we have introduced
OCTM , a higher-order language extending the concurrencymodel of STM Haskell with composable open (multi-thread) transactions. In this language,processes can join transactions and transactions can merge at runtime. These interactions aredriven only by access to shared transactional memory, and hence are implicit and loosely coupled.To this end, we have separated the isolation aspect from atomicity: the atomic construct ensures“all-or-nothing” execution but not isolation, while the new constructor isolated can be usedto guarantee isolation when needed. In order to show the expressive power of
OCTM , we haveprovided an adequate implementation in it of
TCCS m , a recently introduced model of opentransactions with CCS-like communication. As a side result, we have given a simple typingsystem for capturing TCCS m well-formed terms.Several directions for future work stem from the present paper. First, we plan to implement OCTM along the line of STM Haskell, but clearly the basic ideas of
OCTM are quite generaland can be applied to other STM implementations, like C/C++ LibCMT and Java Multiverse.An interesting possibility is to use
TCCS m as an exogenous orchestration language for OCTM : the behaviour of a transactional distributed system can be described as a
TCCS m term, which can be translated into a skeleton in OCTM using the encoding provided in thispaper; then, the programmer has only to “fill in the gaps”. Thus,
TCCS m can be seen as a kindof “global behavioural type” for OCTM .In fact, defining a proper behavioural typing system for transactional languages like
OCTM is another interesting future work. Some preliminary experiments have shown that
TCCS m isnot enough expressive for modelling the dynamic creation of resources (locations, threads, etc.).We think that a good candidate could be a variant of TCCS m with local names and scopeextrusions, i.e., a “transactional π -calculus”.Being based on CCS, communication in TCCS m is synchronous; however, nowadays asyn-chronous models play an important rˆole (see e.g. actors, event-driven programming, etc.). Itmay be interesting to generalize the discussion so as to consider also this case, e.g. by definingan actor-based calculus with open transactions. Such a calculus can be quite useful also formodelling speculative reasoning for cooperating systems [14–16]. A local version of actor-basedopen transactions can be implemented in OCTM using lock-free data structures (e.g., messagequeues) in shared transactional memory.
References [1] M. Abadi, A. Birrell, T. Harris, and M. Isard. Semantics of transactional memory andautomatic mutual exclusion.
ACM Trans. Program. Lang. Syst. , 33(1):2, 2011.[2] R. Bruni, H. C. Melgratti, and U. Montanari. Nested commits for mobile calculi: Extendingjoin. In J. L´evy, E. W. Mayr, and J. C. Mitchell, editors,
Proc. TCS , volume 155 of
IFIP ,pages 563–576. Kluwer/Springer, 2004.[3] V. Danos and J. Krivine. Transactions in RCCS. In M. Abadi and L. de Alfaro, edi-tors,
Proc. CONCUR , volume 3653 of
Lecture Notes in Computer Science , pages 398–412.Springer, 2005.[4] E. de Vries, V. Koutavas, and M. Hennessy. Communicating transactions (extended ab-stract). In P. Gastin and F. Laroussinie, editors,
Proc. CONCUR , volume 6269 of
LectureNotes in Computer Science , pages 569–583. Springer, 2010.165] E. de Vries, V. Koutavas, and M. Hennessy. Liveness of communicating transactions (ex-tended abstract). In K. Ueda, editor,
Proc. APLAS , volume 6461 of
Lecture Notes inComputer Science , pages 392–407. Springer, 2010.[6] J. Gray and L. Lamport. Consensus on transaction commit.
ACM Transactions DatabaseSystems , 31(1):133–160, 2006.[7] T. Harris, S. Marlow, S. L. P. Jones, and M. Herlihy. Composable memory transactions. In
Proc. PPOPP , pages 48–60, 2005.[8] M. Herlihy and J. E. B. Moss. Transactional memory: Architectural support for lock-free data structures. In A. J. Smith, editor,
Proceedings of the 20th Annual InternationalSymposium on Computer Architecture , pages 289–300. ACM, 1993.[9] M. Herlihy and N. Shavit. Transactional memory: beyond the first two decades.
SIGACTNews , 43(4):101–103, 2012.[10] S. L. P. Jones, A. D. Gordon, and S. Finne. Concurrent haskell. In H. Boehm and G. L. S.Jr., editors,
Proc. POPL , pages 295–308. ACM Press, 1996.[11] V. Koutavas, C. Spaccasassi, and M. Hennessy. Bisimulations for communicating transac-tions - (extended abstract). In A. Muscholl, editor,
Proc. FOSSACS , volume 8412 of
LectureNotes in Computer Science , pages 320–334. Springer, 2014.[12] X. Leroy. A formally verified compiler back-end.
Journal of Automated Reasoning ,43(4):363–446, 2009.[13] M. Lesani and J. Palsberg. Communicating memory transactions. In C. Cascaval andP. Yew, editors,
Proc. PPOPP , pages 157–168. ACM, 2011.[14] J. Ma, K. Broda, R. Goebel, H. Hosobe, A. Russo, and K. Satoh. Speculative abductive rea-soning for hierarchical agent systems. In J. Dix, J. Leite, G. Governatori, and W. Jamroga,editors,
Proc. CLMAS , volume 6245 of
Lecture Notes in Computer Science , pages 49–64.Springer, 2010.[15] A. Mansutti, M. Miculan, and M. Peressotti. Multi-agent systems design and prototypingwith bigraphical reactive systems. In K. Magoutis and P. Pietzuch, editors,
Proc. DAIS ,volume 8460 of
Lecture Notes in Computer Science , pages 201–208. Springer, 2014.[16] A. Mansutti, M. Miculan, and M. Peressotti. Distributed execution of bigraphical reactivesystems.
CoRR , abs/1503.02434, 2015.[17] R. Milner.
A Calculus of Communicating Systems , volume 92 of
Lecture Notes in ComputerScience . Springer, 1980.[18] N. Shavit and D. Touitou. Software transactional memory.
Distributed Computing , 10(2):99–116, 1997. 17
Omitted proofs
Proof of Lemma 1.
The proof proceeds by induction on the syntax of
TCCS m . We only showthree cases:1. a transition P τ −→ ε Q resulting from a synchronization outside a transaction;2. a transition P k ( τ ) −−−→ σ Q resulting from a synchronization inside a transaction;3. a commit transition P co k −−→ Q .1. If P τ −→ ε Q with ( Sync ) rule, P = P | P , Q = Q | Q , P a −→ Q , P a −→ Q . P = (( P m i a i .R ′ i ) | P ′ ) \ L such that ∃ i.a i = a and a / ∈ LP = (( P m j b j .R ′′ j ) | P ′ ) \ L such that ∃ j.b j = a and a / ∈ Lη ( P ) = h ([ return t ′ ]) t k ([ return t m ]) t sum k S ′ kk ([ ξ ( a , l sum , R ′ )]) t k · · · k ([ ξ ( a m , l sum , R ′ m )]) t m kk ([ return t ′ ]) t k ([ return t m ]) t sum k S ′ kk ([ ξ ( b , l sum , R ′′ )]) t k · · · k ([ ξ ( b m , l sum , R ′′ m )]) t m ; (Θ , ∅ ) i From hypothesis, there exists a thread t r ∈ { t , . . . , t m } such that([ ̺ ( a r .R ′ r )]) t r = ([ recv a l sum R ′ r ]) t r and exists another thread t s ∈ { t , . . . , t m } s.t.([ ̺ ( a s .R ′′ s )]) t s = ([ send a l sum R ′′ s ]) t s . l sum and l sum are locations created by threads t sum and t sum from the code generatedby encoding of the sums. h· · · k ([ recv a l sum ̺ ( R ′ r )]) t r k ([ send a l sum ̺ ( R ′′ s )]) t s k . . . ; (Θ , ∅ ) i→ ∗ h ([ return t ′ ]) t k ([ return t m ]) t sum k S ′ kk ([ return ]) t k · · · k ([ ̺ ( R ′ r )]) t r k · · · k ([ return ]) t m kk ([ return t ′ ]) t k ([ return t m ]) t sum k S ′ kk ([ return ]) t k · · · k ([ ̺ ( R ′′ s )]) t s k · · · k ([ return ]) t m ; (Θ ′ , ∅ ) i = h S ; Σ i where Θ ′ ( l sum ) = False , Θ ′ ( l sum ) = Falserecv a l sum ̺ ( R ′ r ) and send a l sum ̺ ( R ′′ s ) can in order execute the isolated blocks, andat the end reduce to continuations ̺ ( R ′ r ) and ̺ ( R ′′ s ).Other threads forked by threads t sum , t sum can only reduce to return because Θ ′ ( l sum ) = False and Θ ′ ( l sum ) = False : threads t r , t s modified l -variables through the synchro-nization code inside isolated blocks. We can observe h S ; Σ i ∼ = t η ( Q ), in fact Q = ( R ′ i | P ′ ) \ L | ( R ′′ j | P ′ ) \ L , η ( Q ) = h S q ; Σ q i . η ( Q ) = h ([ return t ′ ]) t k ([ ̺ ( R ′ i )]) t i k S ′ kk ([ return t ′ ]) t k ([ ̺ ( R ′ j )]) t j k S ′ ; (Θ ′ q , ∅ ) i = h S q ; Σ q i where ∀ ch ∈ L ⊎ L . Θ ′ q ( ch ) = M0 h S q ; Σ q i and h S ; Σ i are different only in local variables and for reduced threads, thus h S ; Σ i ∼ = t η ( Q ). 18. If P k ( τ ) −−−→ i,j k Q with ( TSync ) rule, P = ( P | P ), Q = ( Q | Q ), P k ( a ) −−−→ i k Q , P k ( a ) −−−→ j k Q . P = hh P ⊲ i C ii | hh P ⊲ j C ii and P = P | · · · | P m , P = P | · · · | P m . η ( P ) = h ([ P ′ ⊲ ̺ ( C )]) t ,i k ([ P ′ ⊲ ̺ ( C )]) t ,i k ([ ̺ ( P ′ ) ⊲ return ]) t ,i k . . . · · · k ([ recv a l P ′ r ⊲ return ]) t r ,i k · · · k ([ ̺ ( P ′ m ) ⊲ return ]) t m ,i k . . . · · · k ([ ̺ ( P ′ ) ⊲ return ]) t ,j k · · · k ([ send a l P ′ s ⊲ return ]) t s ,j . . . · · · k ([ ̺ ( P ′ m ) ⊲ return ]) t m ,j ; (Θ , ∆) i→ ∗ h ([ P ′ ⊲ ̺ ( C )]) t ,j k ([ P ′ ⊲ ̺ ( C )]) t ,j k . . . · · · k ([ P ′ r ⊲ return ]) t r ,j k · · · k ([ P ′ s ⊲ return ]) t s ,j ; (Θ , ∆ ′ ) i = h S ; Σ ih S ; Σ i ∼ = t η ( Q ) == η ( hh P | · · · | P ′ r | · · · | P m ⊲ k C ii || hh P | · · · | P ′ s | · · · | P m ⊲ k C ii )= h ([ . . . ⊲ ̺ ( C )]) t ,k k ([ . . . ⊲ ̺ ( C )]) t ,k k . . . · · · k ([ P ′ r ⊲ return ]) t r ,k k · · · k ([ P ′ s ⊲ return ]) t s ,k ; (Θ q , ∆ q ) i
3. If P co k −−→ Q with ( TCo ) rule, P = hh R ⊲ k N ii and hh R ⊲ k N ii co k −−→ R ′ where R ′ = Q mi =1 R i η ( P ) = h ([ recv co l t return ⊲ ̺ ( N ); R ]) t,k k ([ return t m ⊲ return ]) t ′ ,k kk ([ ̺ ( R ) ⊲ return ]) t ,k k · · · k ([ ̺ ( R j ) ⊲ return ]) t j ,k k . . . · · · k ([ ̺ ( R m ) ⊲ return ]) t m ,k ; (Θ , ∆) i where∆( l t ) = ( True , k ) , ∆( co ) = ( M0 , k ) R = bang psi ∃ j ∈ { , . . . , m } , R j = co.R ′ j , ̺ ( R j ) = send co l ̺ ( R ′ j ). η ( P ) → ∗ h ([ recv co l t return ⊲ ̺ ( N ); R ]) t,k k ([ return t m ⊲ return ]) t ′ ,k kk · · · k ([ send co l t j ̺ ( R ′ j ) ⊲ return ]) t j ,k k . . . ; (Θ , ∆ ′′ ) i At this point threads t, t j can synchronize through co variable and transaction k can com-19it. → ∗ h ([ recv co l t return ⊲ ̺ ( N ); bang psi ]) t,k kk ([ return t m ⊲ return ]) t ′ ,k k ([ ̺ ( R ) ⊲ return ]) t ,k k . . . · · · k ([ send co l t j ̺ ( R ′ j ) ⊲ return ]) t j ,k k · · · k ([ ̺ ( R m ) ⊲ return ]) t m ,k ; (Θ , ∆ ′′ ) i→ ∗ h ([ return ⊲ ̺ ( N ); bang psi ]) t,k kk ([ return t m ⊲ return ]) t ′ ,k kk ([ ̺ ( R ) ⊲ return ]) t ,k k · · · k ([ ̺ ( R ′ j ) ⊲ return ]) t j ,k k . . . · · · k ([ ̺ ( R m ) ⊲ return ]) t m ,k ; (Θ , ∆ ′′′ ) i co k −−→h ([ bang psi ]) t k ([ return t m ]) t t ′ kk ([ ̺ ( R )]) t k · · · k ([ ̺ ( R ′ j )]) t j k · · · k ([ ̺ ( R m )]) t m ; Σ i = h S ; Σ i where Σ = commit ( k, Θ , ∆ ′′′ ) h S ; Σ i ∼ = t η ( Q ), Q = R ′ = Q m R i and ∃ j ∈ { , . . . , m } : R j = R ′ j η ( Q ) = η ( R ′ ) = h ([ ̺ ( R )]) t k · · · k ([ ̺ ( R ′ j )]) t j k · · · k ([ ̺ ( R m )]) t m ; Σ q i ∼ = t h S ; Σ i Proof of Lemma 2.
The proof goes through induction on the semantic of
TCCS m . Here weshow only 3 cases, first when P are two processes that can perform a synchronization outsidetransactions, second P synchronizes inside transactional processes, third a transactional processcommits.1. If P = a.P | a.P From η ( P ) we can move to another state of the OCTM machine h S ; Σ i and h S ; Σ i ∼ = t η ( Q ): η ( P ) = h ([ return t ′ ]) t k ([ recv a r l ̺ ( P )]) t ′ kk ([ return t ′ ]) t k ([ recv a r l ̺ ( P )]) t ′ ; (Θ ′ , ∅ ) i→ ∗ h ([ return t ′ ]) t k ([ ̺ ( P )]) t ′ k ([ return t ′ ]) t k ([ ̺ ( P )]) t ′ ; (Θ ′ , ∅ ) i = h S ; Σ i where Θ ′ ( l t ) = F alse, Θ ′ ( l t ) = F alse Θ ′ ( a ) = M0 If P τ −→ Q , then Q = P | P , η ( Q ) = h ([ ̺ ( P )]) t k ([ ̺ ( P )]) t ; (Θ q , ∅ ) i , we can observe h S ′ ; Σ ′ i ∼ = t η ( Q ).2. If P = hh a.P ⊲ i Q ii | hh a.P ⊲ j Q ii , η ( P ) → h S ; Σ i → ∗ h S ′ ; Σ ′ i the computations are exactlythe same as the previous point, but all variables are tentative in ∆. It is easy to see that P τ ( k ) −−−→ i,j k Q and h S ; Σ i ∼ = t η ( Q ). 20. If P = hh co.P ′ ⊲ k Q ii η ( P ) == h ([ recv co l return ⊲ ̺ ( Q ); bang psi ]) t,k kk ([ send co l ̺ ( P ′ ) ⊲ return ]) t ′ ,k ; (Θ , ∆) i−→h ([ M ⊲ ̺ ( Q ); bang psi ]) t,k kk ([ send co l ̺ ( P ′ ) ⊲ return ]) t ′ ,k ; (Θ , ∆ ′ ) i = h S ; Σ i where ∆ ′ ( np ) = nonce t → ∗ co k −−→h ([ bang psi ]) t k ([ ̺ ( P ′ )]) t ′ ; (Θ ′ , ∅ ) i where Σ ′ = commit ( k, Θ ′ , ∆ ′ )= h S ′ ; Σ ′ i P = hh co.P ′ ⊲ k N ii co k −−→ P ′ = Q , η ( Q ) = h ([ ̺ ( P ′ )]) t q ; Σ q i , η ( Q ) ∼ = t h S ′ ; Σ ′ ii