Access the full text.
Sign up today, get DeepDyve free for 14 days.
Bratin Saha, Ali-Reza Adl-Tabatabai, Richard Hudson, C. Minh, Ben Hertzberg (2006)
McRT-STM: a high performance software transactional memory system for a multi-core runtime
N. Shavit, D. Touitou (1995)
Software transactional memoryDistributed Computing, 10
Konrad Siek, P. Wojciechowski (2014)
Brief Announcement: Relaxing Opacity in Pessimistic Transactional Memory
A. Matveev, N. Shavit (2012)
Towards a Fully Pessimistic STM Model
M. Herlihy, Victor Luchangco, Mark Moir, William Scherer (2003)
Software transactional memory for dynamic-sized data structures
Yang Ni, Adam Welc, Ali-Reza Adl-Tabatabai, Moshe Bach, Sion Berkowits, J. Cownie, Robert Geva, Sergey Kozhukow, Ravi Narayanaswamy, J. Olivier, S. Preis, Bratin Saha, Ady Tal, Xinmin Tian (2008)
Design and implementation of transactional constructs for C/C++Proceedings of the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications
P. Wojciechowski (2005)
Isolation-only transactions by typing and versioningProceedings of the 7th ACM SIGPLAN international conference on Principles and practice of declarative programming
Håkan Grahn (2010)
Transactional memoryJ. Parallel Distributed Comput., 70
Konrad Siek, P. Wojciechowski (2016)
Atomic RMI 2: Highly Parallel Pessimistic Distributed Transactional MemoryArXiv, abs/1606.03928
P. Felber, Vincent Gramoli, R. Guerraoui (2009)
Elastic transactionsJ. Parallel Distributed Comput., 100
Konrad Siek, P. Wojciechowski (2016)
Atomic RMI: A Distributed Transactional Memory FrameworkInternational Journal of Parallel Programming, 44
Damien Imbs, M. Raynal (2012)
Virtual world consistency: A condition for STM systems (with a versatile protocol with invisible read operations)Theor. Comput. Sci., 444
Simon Doherty, L. Groves, Victor Luchangco, Mark Moir (2009)
Towards formally specifying and verifying transactional memoryFormal Aspects of Computing, 25
Since by Lemma 90 any SVA history H is final-state last-use opaque, and any prefix P of H is also an SVA history, then every prefix of H is also final-state last-use opaque. Thus, by Def
If x P ASetpT i q X ASetpT j q and inv i pstart i q ă ă H|start inv i pstart j q then pv i pxq´1
C. Minh, Jaewoong Chung, C. Kozyrakis, K. Olukotun (2008)
STAMP: Stanford Transactional Applications for Multi-Processing2008 IEEE International Symposium on Workload Characterization
Luke Dalessandro, M. Scott (2012)
Sandboxing transactional memory2012 21st International Conference on Parallel Architectures and Compilation Techniques (PACT)
T. Harris, S. Marlow, S. Peyton-jones, M. Herlihy (2005)
Composable memory transactionsProceedings of the tenth ACM SIGPLAN symposium on Principles and practice of parallel programming
Y. Afek, Adam Morrison, Moran Tzafrir (2010)
Brief announcement: view transactions: transactional model with relaxed consistency checksProceedings of the 29th ACM SIGACT-SIGOPS symposium on Principles of distributed computing
Tadeusz Kobus, Maciej Kokociński, P. Wojciechowski (2015)
The Correctness Criterion for Deferred Update Replication
R. Guerraoui, M. Kapalka (2010)
Principles of Transactional Memory
H. Attiya, Sandeep Hans, P. Kuznetsov, Srivatsan Ravi (2013)
Safety of Deferred Update in Transactional Memory2013 IEEE 33rd International Conference on Distributed Computing Systems
Marek Olszewski, Jeremy Cutler, J. Steffan (2007)
JudoSTM: A Dynamic Binary-Rewriting Approach to Software Transactional Memory16th International Conference on Parallel Architecture and Compilation Techniques (PACT 2007)
C. Papadimitriou (1979)
The serializability of concurrent database updatesJ. ACM, 26
Y. Breitbart, Dimitrios Georgakopoulos, M. Rusinkiewicz, A. Silberschatz (1991)
On Rigorous Transaction SchedulingIEEE Trans. Software Eng., 17
D. Dice, Ori Shalev, N. Shavit (2006)
Transactional Locking II
Michael Ringenburg, D. Grossman (2005)
AtomCaml: first-class atomicity via rollback
Tadeusz Kobus, Maciej Kokociński, P. Wojciechowski (2017)
Relaxing real-time order in opacity and linearizabilityJ. Parallel Distributed Comput., 100
Konrad Siek, P. Wojciechowski (2013)
Towards a fully-articulated pessimistic distributed transactional memoryProceedings of the twenty-fifth annual ACM symposium on Parallelism in algorithms and architectures
M. Lesani, J. Palsberg (2014)
Decomposing Opacity
H. Attiya, Alexey Gotsman, Sandeep Hans, N. Rinetzky (2014)
Safety of Live Transactions in Transactional Memory: TMS is Necessary and Sufficient
(2014)
Transactions are back—but how different they are
Konrad Siek (2014)
Zen and the Art of Concurrency Control: An Exploration of TM Safety Property Space with Early Release in Mind
T. Harris, K. Fraser (2003)
Language support for lightweight transactions
G. Weikum, Gottfried Vossen (2001)
Transactional information systems: theory, algorithms, and the practice of concurrency control and recoverySIGMOD Rec., 30
Y. Afek, A. Matveev, N. Shavit (2012)
Pessimistic Software Lock-Elision
V. Hadzilacos (1988)
A theory of reliability in database systemsJ. ACM, 35
P. Wojciechowski (2007)
Language design for atomicity, declarative synchronization, and dynamic update in communicating systems
Damien Imbs, José Moreno, M. Raynal (2008)
On the Consistency Conditions of Transactional Memories
Hany Ramadan, Indrajit Roy, M. Herlihy, E. Witchel (2009)
Committing conflicting transactions in an STM
Mohamed Saad, Masoomeh Kishi, S. Jing, Sandeep Hans, R. Palmieri (2018)
Processing transactions in a predefined orderProceedings of the 24th Symposium on Principles and Practice of Parallel Programming
Pawel Kobylinski, Konrad Siek, Jan Baranowski, P. Wojciechowski (2016)
Helenos: A realistic benchmark for distributed transactional memorySoftware: Practice and Experience, 48
P. Wojciechowski, Olivier Rütti, A. Schiper (2004)
SAMOA: framework for synchronisation augmented microprotocol approach18th International Parallel and Distributed Processing Symposium, 2004. Proceedings.
Jan Kończak, P. Wojciechowski, R. Guerraoui (2017)
Operation-Level Wait-Free Transactional Memory with Support for Irrevocable OperationsIEEE Transactions on Parallel and Distributed Systems, 28
P. Bernstein, David Shipman, W. Wong (1979)
Formal Aspects of Serializability in Database Concurrency ControlIEEE Transactions on Software Engineering, SE-5
L. Lamport (1977)
Proving the Correctness of Multiprocess ProgramsIEEE Transactions on Software Engineering, SE-3
Dmytro Dziuma, P. Fatourou, E. Kanellou (2014)
Consistency for Transactional Memory Computing
H. Attiya, Alexey Gotsman, Sandeep Hans, N. Rinetzky (2013)
A programming language perspective on transactional memory consistency
R. Guerraoui, M. Kapalka (2008)
On the correctness of transactional memoryProceedings of the 13th ACM SIGPLAN Symposium on Principles and practice of parallel programming
Annette Bieniusa, Arie Middelkoop, Peter Thiemann (2010)
Brief announcement: actions in the twilight - concurrent irrevocable transactions and inconsistency repairProceedings of the 29th ACM SIGACT-SIGOPS symposium on Principles of distributed computing
Adam Welc, Bratin Saha, Ali-Reza Adl-Tabatabai (2008)
Irrevocable transactions and their applications
Maurice Herlihy, J. Moss (1993)
Transactional Memory: Architectural Support For Lock-free Data StructuresProceedings of the 20th Annual International Symposium on Computer Architecture
Travis Skare, Christos Kozyrakis (2006)
Early Release : Friend or Foe ?
D. Perelman, Rui Fan, I. Keidar (2010)
On maintaining multiple versions in STMProceedings of the 29th ACM SIGACT-SIGOPS symposium on Principles of distributed computing
Konrad Siek, P. Wojciechowski (2012)
A Formal Design of a Tool for Static Analysis of Upper Bounds on Object Calls in Java
W. Weihl (1989)
Local atomicity properties: modular concurrency control for abstract data typesACM Trans. Program. Lang. Syst., 11
Publisher's Note Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations
Transaction Memory (TM) is a concurrency control abstraction that allows the programmer to specify blocks of code to be executed atomically as transactions. However, since transactional code can contain just about any operation attention must be paid to the state of shared variables at any given time. E.g., contrary to a database transaction, if a TM transaction reads a stale value it may execute dangerous operations, like attempt to divide by zero, access an illegal memory address, or enter an infinite loop. Thus serializability is insufficient, and stronger safety properties are required in TM, which regulate what values can be read, even by transactions that abort. Hence, a number of TM safety properties were developed, including opacity, and TMS1 and TMS2. However, such strong properties preclude using prerelease as a technique for optimizing TM, because they virtually forbid reading from live transactions. On the other hand, properties that do allow prerelease are either not strong enough to prevent any of the problems mentioned above (recoverability), or add additional conditions on transactions that prerelease variables that limit their applicability (elastic opacity, live opacity, virtual world consistency). This paper introduces last-use opacity and strong last-use opacity, a pair of new TM safety properties meant to be a compromise between strong properties like opacity and minimal ones like serializability. The properties eliminate all but a small class of benign inconsistent views and pose no stringent conditions on transactions. Keywords Transactional memory · Safety property · Consistency 1 Introduction software transactional memory (TM) [22,39]. Basically, TM transplants the transaction abstraction from database systems Writing concurrent programs using low-level synchroniza- and uses it to hide the details of synchronization. In particu- tion primitives is notoriously difficult and error-prone. Over lar, TM uses speculative execution to ensure that transactions the past decade, there has been a growing interest in alterna- in danger of reading inconsistent state abort and retry. This tives to lock-based synchronization by turning to the idea of is a universal solution and means that the programmer must only specify where transactions begin and end, and the TM The research leading to these results received funding from Polish manages the execution so that the transactional code executes National Science Centre, under Grant Agreement No. correctly and efficiently. Thus, the programmer avoids hav- DEC-2012/07/B/ST6/01230. The first author was also supported by ing to solve the problem of synchronization herself and can the Czech Ministry of Education, Youth, and Sports from the Czech Operational Programme Research, Development, and Education, rely on any one of a plethora of TM systems (e.g., [1,12,19– under Grant Agreement No. CZ.02.1.01/0.0/0.0/15_003/0000421. 21,30,31,36,37]). TM allows transactional code to be mixed with non- B Konrad Siek transactional code and to contain virtually any operation, siekkonr@fit.cvut.cz; konrad.siek@gmail.com rather than just reads and writes like in its database predeces- Paweł T. Wojciechowski sors. Therefore, greater attention must be paid to the state of pawel.t.wojciechowski@cs.put.edu.pl shared variables at any given time. For instance, if a database Institute of Computing Science, Poznan University of transaction reads a stale value, it must simply abort and retry, Technology, Piotrowo 2, 60-965 Poznan, Poland and no harm is done. Whereas, if a TM transaction reads an Faculty of Information Technology, Czech Technical inconsistent value it may execute an unanticipated dangerous University in Prague, Thákurova 9, 160 00 Prague 6, Czech operation, like dividing by zero, accessing an illegal mem- Republic 123 266 K. Siek, P. T. Wojciechowski Fig. 1 Example of prerelease ory address, entering an infinite loop or infinite recursion mentations are opaque, illustrating typical behavior of TM (see [11,17]). Such erroneous behavior must be avoided or systems. In an optimistic TM implementation, T reads x mitigated. Mitigation can be done comprehensively by sand- from before T , but tries to read the value of y written by boxing [11] transactions, that is isolating the system from T , conflicts, and needs to abort and restart to avoid reading the damaging effects of inconsistent views at the level of inconsistent values of x and y. In a lock-based pessimistic TM runtime or the operating system. This can mean applying implementation, T waits for T to release a lock on x before k i such diverse techniques managing runtime exceptions, over- reading it. The third implementation uses prerelease. Here, T loading fault signals, forcing periodic transaction validation reads live values of x and y from T , allowing it to finish exe- to capture and contain a broad spectrum of possible errors, cuting much earlier, leading to a shorter schedule overall and etc. [11,32]. Other methods involve requiring programmers less duplicated effort. While this is just one example and the to place validation barriers on sensitive code, or deferring transaction interleavings do not always favor a prereleasing dangerous operations to commit [38]. implementation, the performance gain is visible. However, However, in general, modern TM systems attempt to this execution of T breaks opacity. restrict the ability of transactions to view inconsistent state, Opacity precludes prerelease, because in the general case as formally described by suitable TM safety properties. To reading from live transactions is unsafe. However, in cer- that end, the safety property called opacity [16,17]was tain limited circumstances the harmful operations caused by introduced. This property stipulates as a criterion of cor- inconsistent states can be contained (e.g., by sandboxing), rect execution that transactions do not read values written by or harmful inconsistent states can be identified and elimi- other live (not completed) transactions. It also requires that nated by TM implementations. The question this paper is the execution be both serializable [33] and real-time ordered. concerned with is whether the abandonment of prerelease Opacity became the gold standard of TM safety properties, in the context of safety is necessary or whether prerelease and most TM systems found in the literature are, in fact, can be salvaged, and whether we can codify safe practices to opaque. dictate how to use prerelease safely. However, opacity precludes purposeful and controlled We are, of course, not the first to argue undue restric- reading from live transactions, a technique we will refer to tiveness on the part of opacity. A number of more relaxed as prerelease, which involves transactions that technically properties were introduced that tweaked opacity’s various conflict but nevertheless commit correctly, and produce a aspects to achieve a something more practical. These prop- history that is also correct. This increases the amount of erties include virtual world consistency (VWC) [23] and work transactions can do in parallel, which, improves the transactional memory specification (TMS1 and TMS2) [13] throughput of an implementation. Systems employing pre- which weaken the requirement for a consistent view of release [9,15,26,37] show that this yields a significant and past operations among transactions, and elastic opacity [15] worthwhile performance benefit in practice. This is particu- which allows splitting transactions into smaller fragments. larly (but not exclusively) true for pessimistic concurrency The live opacity [14] property is even interested in allow- control, where prerelease is vital to increased parallelism ing transactions to read from other uncommitted transactions between transactions (see e.g., [40,41]) and therefore essen- while retaining the core guarantees of opacity while restrict- tial for achieving high efficiency in applications with high ing the ability to abort. contention. The first contribution of this paper is to examine these In Fig. 1 we show an example, where transaction T writes properties and determine whether or not they allow the use values to variables x and y, while T , T , and T show the of prerelease in TM, and, if so, what compromises they make j k l behavior of transactions trying to read those variables under with respect to consistency, and what additional assumptions various example TM implementations. The first two imple- they require. We then consider the applicability of these prop- 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 267 erties to TM systems that rely on prerelease. In addition to deterministic and follows the semantics of L. This evalua- TM properties, we similarly examine common database con- tion produces a (possibly empty) sequence of events (steps) sistency conditions: serializability [33], recoverability [18], which we call a trace and denote T E (P,Π). E (P,Π) cascadelessness (avoiding cascading aborts) [8], strictness is concurrent, i.e., while the statements in subprogram P [8], rigorousness [10] and commit-order preservation [44]. are evaluated sequentially by a single process, the evaluation The second contribution of this paper is to introduce new of statements by different processes can be arbitrarily inter- TM safety properties called last-use opacity and strong last- leaved. Hence, given T E (P,Π) and T E (P,Π),itis use opacity that allow prerelease. Each of these is dedicated possible that T = T . to a different transactional model (API). They both eschew stringent assumptions but nevertheless eliminate inconsis- 2.2 Shared variables tent views or restrict them to a benign minimum. This comes at the price of introducing considerations about the code of The system contains a set of shared variables (or just vari- transactions and system invariants into the safety property. ables) Var ={x, y, z,...}. A variable x is an entity that has We give formal definitions, discuss example (strong) last-use state S and a specified interface consisting of the following opaque histories, and compare the new properties with other two operations: discussed properties, specifically showing they are stronger than serializability but weaker than opacity. We also specifi- (a) write operation w(x)v that sets S to value v; the opera- cally enumerate the guarantees given by the properties. tion’s return value is the constant ok (indicating correct The paper is structured as follows. We present the defi- execution), nitions of basic terms in Sect. 2. We then discuss prerelease (b) read operation r (x) whose return value is the current and construct a framework for examining properties through value of S . the lense of prerelease in Sect. 3. We follow by an examina- tion of the TM property space in Sect. 4. Next, we define and Variables are hermetic, meaning that the state S of x can discuss last-use opacity in Sect. 5 and strong last-use opacity only be modified or read by executing write or read operations in Sect. 6. Finally, we present the related work in Sect. 7 and on x. The state S can be defined however, but for simplicity conclude in Sect. 8. We also include an appendix containing we assume its domain is N . additional proofs that we remove from the main text both due Any process p ∈ Π can execute read and write oper- to their size and relative simplicity. ations on x as part of subprogram P . This results in the evaluation of some arbitrary sequence of statements (as part of P ) in language L which have the ability to return and 2 Preliminaries modify S . Whenever process p ∈ Π executes some operation m(x) We begin by introducing basic concepts pertaining to further on variable x as part of P , this causes an invocation event k k discussion, including basic definitions describing transac- inv (m(x)) and a subsequent response event res (v) to be tional memory and execution of programs within it, as well issued, where v is the return value of m(x). The pair of these k k as various system models, and properties. We also explain events (inv (m(x)), res (v)) is called a complete operation the convention we use for diagrams showing transactional execution and it is denoted m (x) → v in shorthand. For the executions. sake of analogy we refer to an invocation event inv (o) with- out the corresponding response event as a pending operation 2.1 Processes execution. The system is composed of processes Π ={ p , p ,..., p } 2.3 Transactions 1 2 n concurrently executing program P which constitutes a set of sequential subprograms P ={P , P ,..., P }, where pro- Transactional memory (TM) is a programming paradigm that 1 2 n cess p executes P . Each subprogram is a finite sequence uses transactions to control concurrent execution of opera- i i of statements in some language L. The definition of L can tions on shared variables by parallel processes. be whatsoever, as long as it provides constructs to execute A transaction T ∈ T is some piece of code executed by transactional operations in accordance with the interface and process p , as part of subprogram P . Hence, we say that k k assumptions described further in this section. p executes T . Any transaction T is executed by exactly k i i Given program P and a set of processes Π, we denote one process p and that each process executes transactions an execution of P by Π as E (P,Π). An execution entails sequentially. Process p can execute local computations as each process p ∈ Π evaluating some prefix of subprogram well as operations on shared variables as part of the transac- P ∈ P. The evaluation of each statement by a process is tion. That is, given x ∈ Var, the process can execute: 123 268 K. Siek, P. T. Wojciechowski (a) write (denoted w (x)v, where i indicates transaction T ) Specifically, in the case of any variable x ∈ Var, given that i i which sets S to v and returns ok if the operation is D is the domain of S , and assuming initially S = v for x i x x 0 successful, and A otherwise, some v ∈ D, the sequential specification of x s.t., Seq(x) is a i 0 (b) read (denoted r (x)) which returns the value of S if the set of sequences of the form [α → v ,α → v ,...,α → i x 1 1 2 2 m execution is successful, or A otherwise. v ], where each α → v ( j = 1, 2,..., m) is either: i m j j In addition, the processes can execute the following transac- (a) w (x)v →ok , where v ∈ D, i j i j tional operations that do not pertain to any specific variable: (b) r (x) →v and there are no preceding writes, or i 0 (c) r (x) →v and the most recent preceding write operation i j (c) start (denoted start ) which initializes transaction T , and i i is w (x)v →ok . l j l whose return value is the constant ok , (d) commit (denoted tryC ) which attempts to commit T and i From this point on, unless stated otherwise, we assume returns either the constant C , which signifies a successful i that the domain D of all transactional variables is the set commitment of the transaction or the constant A in case i of natural numbers N and that the initial value v of each 0 0 of a forced abort, variable is 0. Finally, there is also another operation allowed in some TM 2.5 Histories system models and not in others, which has great impact on consistency, and so we wish to separate it out. Namely, some Givenatrace T E (P,Π),aTM history H is a subsequence TMs allow for a transaction to cause itself to roll back by of trace T consisting only of executions of transactional executing an abort operation: operations s.t. for every event e, e ∈ H iff e ∈ T and e is either an invocation or a response event specified by the (e) abort (denoted tryA ) which aborts T and returns A . i i transactional interface given in Sect. 2.3. The sequence of events in a history H can be denoted We call a TM system model where the abort operation is as H =[e , e ,..., e ]. For instance, some history H j 1 2 m 1 allowed (in addition to other operations) the arbitrary abort below is a history of a run of some program that executes system model, as opposed to the commit-only model. transactions T and T : i j The operations a–e defined above are part of the so- called transactional interface (or transactional API). They H = inv (start ), res (ok ), inv (start ), res (ok ), 1 i i j j i i j j can only be invoked within a transaction. Specifically, pro- cesses execute operations on shared variables only as part of inv (w (x)v), inv (r (x)), res (ok ), res (v), i j i i j i j a transaction. Even though transactions are subprograms evaluated by inv (tryC ), res (C ), inv (tryC ), res (C ) . i j i i i j j j processes, it is convenient to talk about them as separate and independent entities. Thus, rather than saying p executes Some subhistory H of a history H is a subsequence of some operation as part of transaction T , we will simply H. Given any history H,let H |T be the longest subhistory say that T executes some operation. Hence we will also i of H consisting only of invocations and responses executed forgo the distinction of processes in transactional operation by transaction T . For example, H |T is defined as: i 1 j executions, and write simply: start → ok , r (x) → v, i i i w (x)v →ok , tryC → C , etc. By analogy, we also drop the i i i superscript indicating processes in the notation of invocation H |T = inv (start ), res (ok ), 1 j j j j j and response events, unless the distinction is needed. inv (r (x)), res (v), inv (tryC ), res (C ) . j j j j j j j 2.4 Sequential specification Given variable x,let sequential specification of x, denoted We say transaction T is in H, which we denote T ∈ H, i i Seq(x), be a prefix-closed set of sequences containing invoca- iff H |T = ∅. tion events and response events which specify the semantics Let H |x be the longest subhistory of H consisting only of of shared variables. (A set Q of sequences is prefix-closed if, invocations and responses executed on variable x, but only whenever a sequence S is in Q, every prefix of S is also in Q.) those that form complete operation executions. Intuitively, a sequential specification enumerates all possible Given a complete operation execution op that consists of i r correct sequences of operations that can be performed on a an invocation event e and a response event e ,wesay op is i r variable in a sequential execution. in H (op ∈ H)iff e ∈ H and e ∈ H. Given a pending 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 269 operation execution op consisting of an invocation e ,we executions w (x)v → ok and w (x)v → ok it is true that i i j j say op is in H (op ∈ H)iff e ∈ H and there is no other v = v and neither v = v nor v = v . 0 0 operation execution op consisting of an invocation event e and a response event e s.t. op ∈ H. 2.5.3 Completion Given two complete operation executions op and op in some history H, where op contains the response event res Given history H and transaction T , T is committed if H |T i i i and op contains the invocation event inv ,wesay op pre- contains operation execution tryC → C . Transaction T is i i cedes op (or op follows op )in H if res precedes inv in H. aborted if H |T contains response res (A ) to any invocation. i i We denote this op ≺ op . For operations op , op ∈ H, Transaction T is commit-pending if H |T contains invocation i i we say op directly precedes op , denoted op ≺ ≺ op iff tryC but it does not contain res (A ) nor res (C ). Finally, i i i i op ≺ op and op ∈ H s.t. op ≺ op ≺ op . H H H T is live if it is neither committed, aborted, nor commit- A history whose all operation executions are complete is pending. We say a transaction is forcibly aborted if T is a complete history. aborted and H |T does not contain an invocation inv (tryA ). Most of the time it will be convenient to denote any two Given two histories H = e , e ,..., e and H = 1 2 m adjoining events in a history that represent the invocation and [e , e ,..., e ], we define their concatenation as H · H = 1 2 response of a complete execution of an operation as that oper- [e , e ,..., e , e , e ,..., e ].Wesay P is a prefix of H 1 2 m 1 2 m ation execution, using the syntax e → e . Then, an alternative if H = P · H . Then, let a completion Compl(H ) of history representation of H |T is denoted as follows: 1 j H be any complete history s.t., H is a prefix of Compl(H ) and for every transaction T ∈ H subhistory Compl(H )|T i i H |T = start → ok , r (x) →v, tryC → C . equals one of the following: 1 j j j j j In addition, sometimes the values written by particular (a) H |T ,if T finished committing or aborting, i i operations, or returned by them will not be relevant to the (b) H |T · res (C ) ,if T is live and contains a pending i i i discussion at hand. In those situations we use the place- tryC , holder value to indicate that whatever value was passed or returned. For instance, when the value returned by the (c) H |T · res (A ) ,if T is live and contains some pending i i i read operation is irrelevant in H |T , we denote it as follows: 1 j operation, (d) H |T · tryC → A ,if T is live and contains no pending i i i H |T = start → ok , r (x) → , tryC → C . 1 j j j j j operations. 2.5.1 Well-formedness Note that, if all transactions in H are committed or aborted History H is well-formed if, for every transaction T in H, i then Compl(H ) and H are identical. H |T is an alternating sequence of invocations and responses s.t., 2.5.4 Equivalency (a) H |T starts with an invocation inv (start ), i i Two histories H and H are equivalent (denoted H ≡ H ) (b) no events in H |T follow res (C ) or res (A ), i i i i i if for every T ∈ T it is true that H |T = H |T . When i i i (c) no invocation event in H |T follows inv (tryC ) or we say H is equivalent to H we mean that H and H are inv (tryA ), equivalent. (d) for any two transactions T and T s.t., T and T are i j i j executed by the same process p , the last event of H |T k i precedes the first event of H |T in H or vice versa. j 2.5.5 Real-time order In the remainder of the paper we assume that all histories are A real-time order ≺ is an order over history H s.t., given well-formed. two transactions T , T ∈ H, if the last event in H |T pre- i j i cedes in H the first event of H |T , then T precedes T in j i j 2.5.2 Unique writes H, denoted T ≺ T . We then say that two transactions i H j T , T ∈ H are concurrent if neither T ≺ T nor T ≺ T . i j i H j j H i History H has unique writes if, given transactions T and We say that history H preserves the real-time order of H if T (where i = j or i = j), for any two write operation ≺ ⊆≺ . j H H 123 270 K. Siek, P. T. Wojciechowski 2.5.6 Sequential histories transaction legality. Intuitively, using variables as an exam- ple, we can say a transaction is legal in a sequential history A sequential history S is a history, s.t. no two transactions in S if it only reads values of variables that were written by com- are concurrent in S. Some sequential history S is a sequential mitted transactions or by itself. witness history of H if S is equivalent to H and S preserves More formally, let S be a sequential history that only the real time order of H. We usually denote such a history contains committed transactions, with the possible excep- S . tion of the last transaction, which can be aborted. We say that sequential history S is legal if for every x ∈ Var, 2.5.7 Accesses S|x ∈ Seq(x ). In addition, given any sequential history S and transaction Given a history H and a transaction T in H, we say that T T ∈ S,let visible history Vis(S, T ) be the longest subhistory i i i i accesses some variable x in H iff there exists some invocation of S s.t., for every transaction T ∈ Vis(S, T ), either i = j or j i by T on x of any operation m(x) in H |T . In addition, let T ’s T is committed in S and T ≺ T . Then, given a sequential i i i j j S i access set, denoted ASet(i ),in H be a set that contains every history S and a transaction T ∈ S, we say that T is legal in i i variable x such that T accesses x in H. S if Vis(S, T ) is legal. i i With respect to variables specifically, T reads variable x in H if there exists an invocation inv (r (x)) in H |T .By i i 2.7 Safety properties analogy, we say that T writes to x in H if there exists an invocation inv (w (x)v) in H |T . In addition, let T ’s read set i i i A property P is a condition that stipulates correct behavior. In be a set that contains every variable x such that T reads x.By i relation to histories, a given history satisfies P if the condition analogy, T ’s write set contains every x such that T writes to i i is met for that history. Given property P, we call H the set x. A transaction’s access set, denoted ASet(i ), is the union of all P-histories, defined such that H ∈ H if, and only if of its read set and its write set. H satisfies P. In relation to programs, program P satisfies P Given a history H (with unique writes) and a pair of trans- if all histories produced by P satisfy P. actions T , T ∈ H,wesay T reads from T if there is some i j i j Safety properties [28] are properties which guarantee that variable x, for which there is a complete operation execu- “something [bad] will not happen.” In the case of TM this tion w (x)v → ok in H |T and another complete operation j j j means that, transactions will not observe concurrency of execution r (x) →u in H |T , s.t. v = u. i i other transactions. Property P is a safety property if it meets the following definition (adapted from [6]): 2.5.8 Locality Definition 1 A property P is a safety property if, given the set H of all histories that satisfy P: Given any transaction T in some history H , any operation execution on a variable x within H |T is either local or non- (a) Prefix-closure: every prefix H of a history H ∈ H is local. Read operation execution r (x) → v in H |T is local i i also in H , if it is preceded in H |T by a write operation execution on (b) Limit-closure: for any infinite sequence H , H ,... of 0 1 x, and it is non-local otherwise. Write operation execution finite histories, s.t. for every h = 0, 1,..., H ∈ H and h P w (x)v → ok in H |T is local if it is followed in H |T by a i i i i H is a prefix of H , the infinite history that is the limit h h+1 write operation execution on x, and non-local otherwise. of the sequence is also in H . 2.5.9 Conflicts For distinction, we use the term consistency condition to refer to properties that are not safety properties. Following [17], transaction conflicts are defined for variables We compare properties with respect to their relative as follows. Given a history H and a pair of transactions strength. Given two properties P and P we say P is T , T ∈ H,wesay T and T conflict on variable x in H i j i j stronger than P if H ⊂ H (so P is weaker than P ). if T and T are concurrent, both T and T access x, and one i j i j P P If neither H ⊂ H nor H ⊃ H , then the properties or both of T and T write to x. We call any two operation exe- i j P P P P are incomparable, which we denote H H . cutions on some x that cause two transactions T , T (i = j) i j P P to conflict on x conflicting operation executions. 2.8 Invariants 2.6 Transaction legality An invariant expresses constant properties of a system. They The definitions given above allow us to formulate the central can be provided by programmers writing transactional code concept that defines consistency of transactional execution: or implemented as part of a TM implementation. Program- 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 271 Fig. 2 Transaction diagram for H mers can assume that invariants are true at the beginning of 2.9 Transaction diagrams transactions and write their code to assure that they are true at the end of transactions. Invariants do not have to be main- When talking about examples of histories, it is easier to tained for the duration of the transaction, as long as they understand the relationships between various events if the are true at their end. An invariant can be declared for all history is depicted using diagrams. For example, the follow- transactions or a set of specific transactions. Invariants can ing history is represented in the diagram in Fig. 2: be expressed on a single variable (e.g.,x>0) or multiple variables (e.g.,x==y== z). H = start → ok , start → ok , inv (r (x)), 2 i i j j j We abstract from the semantics of invariants and only observe them as arbitrary black-box functions defined over w (x)1 →ok , res (1), tryA → A , i i i j i sets of shared variables that apply to an explicitly stated set w (x)2 →A , start → ok , j j k k of transactions (including all transactions). For our purposes, an invariant is a pair consisting of a set of variables—its r (x) →0, w (x)1 →ok , tryC → C . k k k k domain—and the set of transactions it applies to. We denote the set of all invariants in a system as I. Additionally, by This and other diagrams each depict a history consisting of I we denote the set containing variable x and all variables operations executed by transactions on a time axis. Every line contained in the domain of any invariant that contains x and depicts the operations executed by a particular transaction. applies to transaction T . The symbol denotes a complete operation execution. The For the sake of subsequent discussion we define three spe- inscriptions above operation executions denote operations cific examples of invariant sets. executed by the transactions, e.g. r (x) → 0 denotes that a read operation on variable x is executed by transaction T and I denotes an empty invariant set. This refers to systems returns 0, and w (x)1 → ok denotes that a write operation i i where programmers make no specific assumptions about writing 1 to x is executed by T , and tryC → C indicates i i i values of shared variables or their relationships with other that T attempts to commit and succeeds because it returns C , i i variables. whereas tryA →A indicates that the transaction attempts to 1 i I denotes a set containing only such invariants whose abort and succeeds, etc. On the other hand, the symbol domains are either empty or singletons. This describes denotes an operation execution split into the invocation and systems where there are no relationships between shared the response event to indicate waiting, or that the execution variables, but there are constraints on shared variables takes a long time. In that case the inscription above is split specified in terms of static values or local variables. between the events, e.g., a read operation execution would I denotes a set containing an invariant that applies to all show r (x) above the invocation, and→1 over the response. transactions and whose domain is Var. This represents The diagram also adds additional information to the his- systems where no specific invariants are defined, but there tory to emphasize relationships between events. If waiting is an overarching assumption that all variables are related. is involved, the arrow is used to emphasize a happens In the context of transactional execution it means that it before relation between two events. The same is used to indi- is assumed that a transaction modifying a set of variables cate causality, e.g. whenever an abort event forces another cannot expose the state of these variables to other trans- operation to abort. Furthermore, denotes that the pre- actions until it finishes all of its intended modifications. ceding transaction aborts (here, T ) and a new transaction (T ) is spawned. These elements are used as necessary to Unless stated otherwise, we assume I . indicate particular scenarios and may be omitted. 123 272 K. Siek, P. T. Wojciechowski Definition 2 (Prerelease) Given history H (with unique writes), transaction T ∈ H prereleases variable x in H iff there is some prefix P of H, such that T is live in P and there exists some transaction T ∈ P such that there is a complete non-local read operation execution op = r (x) →v in P|T j j and a complete write operation execution op = w (x)v → Fig. 3 A history with prerelease ok in P|T such that op ≺ op . i i P i j 3.2 Key questions 3 Prerelease The overall theme of this work is to examine safety proper- We begin our analysis by defining its key questions. The first and the most obvious is whether a particular property ties and consistency conditions in terms of prerelease. What, then, is prerelease exactly and what impact does it have on supports prerelease at all. Prerelease pertains to a situation where conflicting transactions execute partially in parallel consistency? Prerelease pertains to a situation where conflicting trans- while accessing the same variable. The implied intent is for all such transactions to access these variables without losing actions execute partially in parallel while accessing the same variable. In other words, prerelease is the ability of transac- consistency and thus for them all to finally commit. We define prerelease formally in Definition 2. Then, the ability for a tions to read from live transactions. The implied intent is for all such transactions to access these variables without losing property to support prerelease is defined as follows: consistency and thus for them all to finally commit. We show Definition 3 (Prerelease Support) Property P supports pre- an example of this in Fig. 3 Here, transaction T writes value release iff given some history H that satisfies P there exists 1to x, and subsequently T reads 1 from x, but does so with- some transaction T ∈ H, s.t. T prereleases some variable x i i out waiting for T to commit. Thus, T prereleased x for T j i j in H. to access. The advantage of letting this happen is that the width of If a property allows prerelease, it allows a significant the schedule is shortened, which translates in some way into performance boost (see e.g., [35,41]) as transactions are exe- throughput. Then, if a TM system or a TM property allows cuted with a higher degree of parallelism. it, there is a potential pragmatic benefit. There are also pitfalls. What if T write to x again after T i j 3.3 Overwriting support reads from x? Transactions are supposed to be atomic and isolated, so this behavior, reading a value from the middle of Prerelease can give rise to some unwanted or unintuitive sce- a transaction, should be treated as a clear violation. narios with respect to consistency. The most egregious of But what if T eventually aborts instead of committing? these is overwriting, where one transaction prereleases some Clearly T must then be forced to abort too. This can poten- variable, but proceeds to modify it afterward. In that case, any tially cause other transactions to be forced to abort as well, transaction that started executing operations on the released which is a costly effect. On the other hand to prevent the variable will observe an intermediate value with respect to situation we must either forbid prerelease or prevent T from the execution of the other transaction, ie., view inconsistent aborting after prerelease. Creating such irrevocable transac- state. tion comes with its own problems, but, more importantly, An example of overwriting is shown in Fig. 4, where trans- is precluded in many classes of TM systems, including dis- action T prereleases variable x but continues to write to x tributed TM, so at least that limitation should be considered i afterward. As a consequence, T first reads the value of x too stringent. j that is later modified. When T detects it is in conflict while executing a write operation it is aborted. This is a way for 3.1 Definition of prerelease the TM to attempt to mitigate the consequences of viewing inconsistent state. The transaction is then restarted as a new Our definitions are based on the observed effects of the transaction T . release without reference to the actions of a concurrency However, as argued in [17], simply aborting a transaction control algorithm. That is a variable is considered to be pre- that views inconsistent state is not enough, since the transac- released by some transaction only when it is live and another tion can potentially act in an unpredictable way on the basis transaction views the modifications applied to the variable of using an inconsistent value to perform local operations. by the first transaction. We define the concept of prerelease For instance, if the value is used in pointer arithmetic it is as follows: possible for the transaction to access an unexpected memory 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 273 Fig. 4 A history with prerelease and overwriting location and crash the process. Alternatively, if the transac- and hardware TM, where aborts can be caused by outside tion uses the value within a loop condition, it can enter an stimuli, such as machine crashes. infinite loop and become parasitic. Other dangerous behav- An exception to this may be found in systems making iors are possible, including division by zero precluded by special provisions to ensure that irrevocable transactions invariants that assume atomicity of transactions. eventually commit (see e.g., [27,45]). In such systems, Thus, in our analysis of existing properties we ask the prereleasing transactions could be ensured never to abort. question whether, apart from allowing prerelease, the prop- However, case in point, these take drastic measures to ensure erties also forbid overwriting. In the light of the potential that, e.g., at most a single irrevocable transaction is present dangerous behaviors that can be caused by it, we consider in the system at one time. Therefore, the requirement is too properties that allow overwriting to be too weak to be prac- strict in the general case. tical. Definition 5 (Aborting Prerelease Support) Property P sup- Definition 4 (Overwriting Support) Property P supports ports aborting prerelease iff P supports prerelease, and given overwriting iff P supports prerelease, and given some his- some history H that satisfies P, for some transaction T ∈ H tory H (with unique writes) that satisfies P, for some pair of that prereleases some variable x, H |T contains A . i i transactions T , T ∈ H s.t., i j (a) T prereleases some variable x, 4 Properties and prerelease (b) H |T contains two write operation executions: w (x)v → i i ok and w (x)v →ok , s.t. the former precedes the latter In this section we analyze the extent to which various prop- i i i in H |T , erties support prerelease, and what restrictions they apply to (c) H |T contains a read operation execution r (x) →v that transactions that prerelease variables. The properties under j j precedes w (x)v →ok in H . consideration are the typical TM safety properties: seri- i i alizability, opacity, markability, virtual world consistency, 3.4 Aborting prerelease support transactional memory specification, live opacity, and elastic opacity. We also consider some strong database consistency In addition, we look at whether or not a particular prop- conditions that pertain to transactional processing: recov- erty forbids a transaction that prereleases some variable to erability, commitment order preservation, cascadelessness, abort. This is a precaution taken by many properties to pre- strictness, and rigorousness. vent cascading aborts, another type of scenario involving inconsistent views. An example of this is shown in Fig. 5.In 4.1 Serializability such a case a transaction, here T , prereleases a variable and subsequently aborts. This can cause another transaction T The first property we discuss is serializability, a database that executed operations on that variable in the meantime to property which can be regarded as a baseline TM safety observe inconsistent state. In order to maintain consistency, property. It can be considered the minimal strong property a TM will then typically force T to abort and restart (as a acceptable in TM. It is also a property that can be grasped new fresh transaction T ). k intuitively: a history is serializable if there is some sequential However, while the condition that no transaction that execution that would reflect the same behavior as shown in prereleases a variable can abort, solves the problem of cas- that history. cading aborts, it significantly limits the usefulness of any Serializability is defined formally in [33] in three variants: TM that satisfies it, since TM systems typically cannot pre- conflict serializability, view serializability, and final-state dict whether any particular transaction eventually commits serializability. We follow a more general version of serializ- or aborts. In particular, there are important applications for ability defined in [43](as global atomicity), which we adjust TM, where a transaction can arbitrarily and uncontrollably to account for non-atomicity of commits in our model. abort at any time. Such applications include distributed TM 123 274 K. Siek, P. T. Wojciechowski Fig. 5 A history with prerelease and cascading abort Definition 6 (Serializability) History H is serializable iff 4.2 Commitment order preservation there exists some sequential history S equivalent to a com- pletion Compl(H ) such that any committed transaction in S Commitment order preservation (CO) is a database consis- is legal in S. tency condition, which requires that transactions commit in the same order as the order in which the transactions accessed Intuitively, the definition does not preclude prerelease, as variables. It is often used as an additional condition to seri- long as illegal transactions are aborted. Serializability also alizability. Formally, CO is defined as follows (adapted from makes no further stipulations on aborting transactions, so it [44]): permits both overwriting and cascading aborts. Definition 7 (Commitment Order Preservation) History H preserves commitment order iff for any two committed con- Lemma 1 Serializability supports prerelease. flicting transactions T , T ∈ H s.t. i = j given any pair of i j Proof Let H be a transactional history as shown in Fig. 4. conflicting operation executions op ∈ H |T and op ∈ i j Note that since all transactions in H are committed or aborted H |T , either op ≺ op and res (C ) ≺ res (C ),or j H i H j i j i j then H = Compl(H ). Then, let there be a sequential history op ≺ op and res (C ) ≺ res (C ). H j H i j i j i ˆ ˆ S = H |T · H |T · H |T . Note that S ≡ H. Trivially, all H i j k H CO maintains the order of their commits with respect to the ˆ ˆ the committed transactions, T and T ,in S are legal in S , i k H H order in which they access operations, but it makes no stip- so H is serializable. Since, by Definition 2, T prereleases a ulations regarding aborted transactions, which allows them variable in H, then, by Definition 3, serializability supports to read from live transactions. Thus, prerelease is generally prerelease. allowed under commit ordering. Lemma 2 Serializability supports overwriting. Lemma 4 Commitment order supports prerelease. Proof Let H be a transactional history as shown in Fig. 4. Proof Let H be a serializable history as in the proof of Here, all operations in T conflict with all operations in T , Lemma 1 above. Transaction T writes 1 to x in H prior i j and all operations in T conflict with all operations in T . to T reading 1 from x, and subsequently T writes 2 to x. i k j i In addition, transactions T and T commit. Since T per- Thus, according to Definition 4, serializability supports over- i k k forms its operations on the shared variable after T , then T writing. i k must commit after T . Since this is the case, H preserves Lemma 3 Serializability supports aborting prerelease. commitment order (Definition 7). Since, by Definition 2, T prereleases a variable in H, then, by Definition 3, commit Proof Let H be a history such as the one in Fig. 5. Since ordering supports prerelease. all transactions in H are committed or aborted then H = ˆ Lemma 5 Commitment order supports overwriting. Compl(H ). Then, let S be a sequential history equivalent ˆ ˆ to H such that S = H |T · H |T · H |T . S contains only H i j k H Proof By analogy to Lemma 4. one committed transaction T , which is trivially legal in S . k H Lemma 6 Commitment order supports aborting prerelease. Thus H is serializable. In addition, transaction T in S both i H prereleases x (by Definition 2) and contains an abort (A ∈ Proof Let H be a history such as the one in Fig. 5. Here, only H |T ). Thus, by Definition 5, serializability supports aborting transaction T commits, so trivially, the history preserves prerelease. commitment order by Definition 7. Transaction T in H pre- releases x (Definition 2) and contains an abort (A ∈ H |T ). i i There is also a variant of serializability called strict seri- Thus, by Definition 5, CO supports aborting prerelease. alizability that adds the condition that the witness history S which justifies the serializability of history H must also pre- Note that, a composition of CO with either serializability serve the real-time order of H. The results above trivially or recoverability (see below) trivially also allows prerelease, extend to this variant. overwriting, and aborting prerelease. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 275 4.3 Recoverability Definition 9 (Cascadelessness) History H is cascadeless iff for any T , T ∈ H s.t. i = j and T reads from T , T i j j i i Recoverability is another database consistency condition commits before the read. used in conjunction with serializability. Recoverability Cascadelessness restricts reading from live transactions. requires that transactions only commit after other transac- Therefore, cascadelessness clearly removes all the scenarios tions whose changes they read have committed. It is defined encompassed by Definition 2. Since this is the only provision as below (following [18]): of cascadelessness, the property forbids prerelease without Definition 8 (Recoverability) History H is recoverable iff giving any additional guarantees. Hence, it also does not sup- for any T , T ∈ H, s.t. i = j and T reads from T , T port overwriting nor aborting prerelease. i j j i i commits in H before T commits. Lemma 10 Cascadelessness does not support prerelease. Recoverability requires that transactions only commit Proof By contradiction let us assume that cascadelessness after other transactions, whose changes they read, have com- supports prerelease. Then, from Definition 3, there exists mitted, which does not impinge on the ability to prerelease. some cascadeless history H, s.t. there exists some transac- Lemma 7 Recoverability supports prerelease. tion T ∈ H that prereleases some variable x in H.From Definition 2, this implies that there exists some prefix P of Proof Let H be a transactional history as shown in Fig. 4. H s.t. Here, transaction T reads from T and T reads from T , and j i k i no other transactions are in the reads-from relation. If H is (a) there is an operation execution op = w (x)v → ok and i i recoverable, then, by Definition 8, T must commit before T i j op ∈ P|T , commits and before T commits. This condition is true for (b) there exists a transaction T ∈ P (i = j) and an operation T and T , since T never commits. The condition is trivially i j j execution op = r (x) → v, s.t. op ∈ P|T and op j j j j i true for T and T . Hence, H is recoverable. Since, by Defi- i k precedes op in P, nition 2, T prereleases a variable in H, then, by Definition 3, (c) T is live in P. recoverability supports prerelease. These imply that op follows op in P in such a way that there j i Lemma 8 Recoverability supports overwriting. does not exist in P an operation op = tryC → C in P s.t. c i op ≺ op . Therefore, such op does not exist in H either. c j c Proof By analogy to Lemma 7. This contradicts Definition 9, which dictates that T must commit before T reads from T ,so H is not cascadeless, Lemma 9 Recoverability supports aborting prerelease. j i which is a contradiction. Proof Let H be a history such as the one in Fig. 5. Here, Since both Definitions 4 and 5 require prerelease support, transaction T reads from T and no other transactions are in j i then: the reads-from relation. Since T and T both abort, then, the i j condition in Definition 8 is trivially true for H. Hence, H is Corollary 1 Cascadelessness does not support overwriting. recoverable. Transaction T in H prereleases x (Definition 2) and contains an abort (A ∈ H |T ). Thus, by Definition 5, i i Corollary 2 Cascadelessness does not support aborting pre- recoverability supports aborting prerelease. release. Note that, a composition of recoverability and serializabil- 4.5 Strictness ity or commitment order preservation also allows prerelease, overwriting, and aborting prerelease. Strictness [8] is a strong database property that, given a write in one transaction, and some other following operation in 4.4 Cascadelessness another transaction, that second operation can only be exe- cuted if the transaction executing the write already committed Cascadelessness (also known as avoiding cascading aborts or aborted. Formally: or rollbacks—ACA, ACR) is a database consistency condition that is used to exclude scenarios where one aborting trans- Definition 10 (Strictness) History H is strict iff for any action T forces another transaction T to abort, because T T , T ∈ H (i = j) and given any operation execution i j j i j read from T before T aborted. It is used to impose addi- op = r (x) → v or op = w (x)v → ok in H |T , and i i i i i i i i tional requirements on serializable executions. It is defined any operation execution op = w (x)v → ok in H |T ,if j j j as follows (after [8]): op follows op , then T commits or aborts before op . i j i 123 276 K. Siek, P. T. Wojciechowski The definition unequivocally states that a transaction can- Definition 12 (Opacity) A TM history H is opaque if, and not read from another transaction, until the latter is committed only if, every finite prefix of H is final-state opaque. or aborted. Thus, strictness precludes prerelease altogether. This definition of opacity forbids reading from live trans- Lemma 11 Strictness does not support prerelease. actions, so it precludes any use of prerelease whatsoever. Proof By contradiction let us assume that strictness supports Lemma 12 Opacity does not support prerelease. prerelease. Then, from Definition 3, there exists some history H, s.t. H is strict and there exists some transaction T ∈ H Proof By contradiction let us assume that opacity supports that prereleases some variable x in H. From Definition 2,this prerelease. Then, from Definition 3, there exists some history implies that there exists some prefix P of H s.t. H (with unique writes), s.t. H is opaque and there exists some transaction T ∈ H that prereleases some variable x in H. (a) there is an operation execution op = w (x)v → ok and i i From Definition 2, this implies that there exists some pre- op ∈ P|T , fix P of H s.t. (b) there exists a transaction T ∈ P (i = j) and an operation execution op = r (x) → v, s.t. op ∈ P|T and op j j j j i (a) there is an operation execution op = w (x)v → ok and precedes op in P, i i op ∈ P|T , (c) T is live in P. i i (b) there exists a transaction T ∈ P (i = j) and an operation execution op = r (x) → v, s.t. op ∈ P|T and op j j These imply that op follows op in P in such a way that j j i j i precedes op in P, there does not exist in P an operation op that returns either (c) T is live in P. A or C and op ≺ op ≺ op . Therefore, there does not i i P P i c j exist an operation op in H that returns either A or C and i i op ≺ op ≺ op . This contradicts Definition 10,so H H H Let P be any completion of P. Since T is live in P, by defi- i c j c i is not strict, which is a contradiction. nition of completion, it is necessarily aborted in P (ie. A ∈ c i P |T ). Given any sequential history P equivalent to P , c i c c Since both Definitions 4 and 5 require prerelease support, ˆ ˆ since T is aborted in P and Vis(P , T ) only contains oper- i c c j then: ations of committed transactions, then P |T Vis(P , T ). c i c j ˆ ˆ Corollary 3 Strictness does not support overwriting. This means that op ∈ Vis(P , T ) but op ∈ / Vis(P , T ),so c j c j j i ˆ ˆ Vis(P , T ) Seq(x) and therefore Vis(P , T ) is not legal. c j c j Corollary 4 Strictness does not support aborting prerelease. On the other hand, Definition 12 implies that any prefix P of H is final state opaque, which, by Definition 11,implies Note, that while strictness does not allow prerelease as that there exists some completion P of P for which there defined by Definition 2, it allows for parallel execution of ˆ ˆ exists an equivalent sequential history P s.t., any T in P c j c reads by live transactions which can be considered a limited ˆ ˆ is legal in P . Since any T is legal in P then for all T , c j c form of prerelease (e.g. [21]). Vis(P , T ) is also legal. But this is a contradiction with the paragraph above. Thus, there cannot exist a history like H 4.6 Opacity that is both opaque and contains a transaction that prereleases some variable. Opacity [16,17] can be considered the standard TM safety property that guarantees serializability and preservation of Since both Definitions 4 and 5 require prerelease support, real-time order, and prevents reading from live transactions. then: It is defined by the following two definitions. The first defini- tion specifies final state opacity that ensures the appropriate Corollary 5 Opacity does not support overwriting. guarantees for a complete transactional history. The second definition uses final state opacity to define a safety property Corollary 6 Opacity does not support aborting prerelease. that is prefix-closed. Both definitions follow those in [17]. Definition 11 (Final state opacity) A finite TM history H It is worth noting that opacity precludes reading from live is final-state opaque if, and only if, there exists a sequential transactions even if the read can be performed safely. For history S equivalent to any completion of H s.t., instance, a transaction that writes a value, does not overwrite it, and is guaranteed to eventually commit by the implemen- (a) S preserves the real-time order of H, tation, still cannot expose this value to other transactions (b) every transaction T in S is legal in S. i before the writer transaction commits. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 277 4.7 Markability correctness of an operation’s response in the following def- initions (see the definitions of extConsPrefix and validResp Markability [29] is a TM safety property equivalent to opac- for TMS1 in [13]). ity (i.e. every opaque history is markable, and every markable Given history H and some response event r in H,let H↑r history is opaque) introduced as a simpler way to prove opac- denote a subhistory of H, s.t. for every operation execution ity. Since every markable history is opaque, then it follows op ∈ H, op ∈ H↑r iff op ≺ r and op is complete. This rep- from Lemma 12, and Corollaries 5 and 6, that: resents all operations executed “thus far,” when considering the legality of r. Corollary 7 Markability does not support prerelease. c c Let T be the set of all such transactions that T ∈ T iff H H T ∈ H and inv (tryC ) ∈ H |T (or inv (tryA ) ∈ H |T ). k k k k k k k Corollary 8 Markability does not support overwriting. This set represent transactions which either committed or aborted (i.e., transactions that are not live). Given response Corollary 9 Markability does not support aborting prere- event r,let T ↑ r be the set of all transactions in H s.t. lease. H c c T ∈ T ↑r if T ∈ T and inv (tryC ) ≺ r. This set k k H H H k represents all transactions that either committed or aborted 4.8 Rigorousness before response event r. Given some history H,let T by any subset of trans- Rigorousness is a strong database property which requires H actions in H.Let σ be a sequence of transactions. Let that given any two transactions executing operations on the ser(T , ≺ ) be a set of all sequences of transactions s.t. same variable, the latter of them cannot execute any opera- H σ ∈ ser(T , ≺ ) if σ contains every element of T exactly tions until the former commits or aborts. It is defined as a H H once, and, for any T , T ∈ T ,if T ≺ T then T precedes i j i H j i condition added onto strictness, as follows (following [10]): H T in σ . Definition 13 (Rigorousness) History H is rigorous iff it is Given a history H and some response event r in H, strict and for any T , T ∈ H (i = j) such that T writes to let ops(σ, r ) be a sequence of operations s.t. if σ = i j i variable x, i.e., op = w (x)v →ok ∈ H |T after T reads x, [T , T ,..., T ] then ops(σ, r ) = H↑r |T · H↑r |T ·... · H↑ i i i j 1 2 n 1 2 then T commits or aborts before op . r |T . This represents the sequential history prior to response j n event r that respects a specific order of transactions defined Since in [5] the authors demonstrate that rigorous histories by σ . are opaque, and since we show in Lemma 12 and Corollaries 5 The most relevant condition in TMS1 with respect to and 6 that opaque histories do not support prerelease, then our further discussion is the validity condition of individ- neither does rigorousness. ual response operations. A prerequisite for checking validity is to check whether a response event can be justified by some Corollary 10 Rigorousness does not support overwriting. externally consistent prefix. This prefix consists of opera- tions from all transactions that precede the response event Corollary 11 Rigorousness does not support overwriting. and whose effects are visible to other transactions. Specif- Corollary 12 Rigorousness does not support aborting prere- ically, if a transaction precedes another transaction in the lease. real time order, then it must be both committed and included in the prefix, or both not committed and excluded from the 4.9 Transactional memory specification prefix. However, if a transaction does not precede another transaction, it can be in the prefix regardless of whether it In [13] the authors argue that some scenarios, such as sharing committed or aborted. variables between transactional and non-transactional code, Definition 14 (Externally Consistent Prefix) Given a history require additional safety properties. Thus, they propose and H and a response event r, let the externally consistent prefix rigorously define two consistency conditions for TM: trans- T be any subset of all transactions in H s.t. for any T , T ∈ i j actional memory specification 1 (TMS1) and transactional r r T ,if T ≺ T then T is in T iff res (C ) ∈ H↑r |T . i H j i i i H H i memory specification 2 (TMS2). TMS1 follows a set of design principles including a TMS1 specifies that each response to an operation invo- requirement for observing consistent behavior that can be cation in a safe history must be valid. Intuitively, a valid justified by some serialization. Among others, TMS1 also response event is one for which there exists a sequential pre- requires that partial effects of transactions are hidden from fix that is both legal and meets the conditions of an externally other transactions. These principles are reflected in the def- consistent prefix. More precisely, the following condition inition of the TMS1 automaton. We paraphrase only parts must be met: relevant to our further discussion, i.e. the condition for the 123 278 K. Siek, P. T. Wojciechowski Definition 15 (Valid Response) Given a transaction T in H, we say the response r to some operation invocation e in H |T r c is valid if there exists set T ⊆ T ↑r and sequence σ ∈ H H r r ser(T , ≺ ) s.t. T satisfies Definition 14 and ops(σ ·T , r )· H i H H [e → r ] is legal. Fig. 6 VWC history with prerelease Intuitively, TMS1 specifies that each response to an oper- (a) T and T are executed by the same process p and i j k ation in a safe history must be valid (Definition 15), which k k res (C ) ≺ inv (start ),or i H j i j means it is explained by a sequential prefix that is both (b) T reads from T ,or j i legal and meets the conditions of an externally consistent PO PO (c) there exists some T ∈ H such that T ≺ T and T ≺ l i l l H H prefix (Definition 14). Since the externally consistent prefix T . excludes live transactions, then TMS1 does not allow prere- lease in general. More formally: The authors of the property remark further that there is PO PO no ≺ relation between T and T (T ≺ T )if T is Lemma 13 TMS1 does not support prerelease. i j i j i H H aborted (where T can commit or abort). We say sequen- Proof Assume by contradiction that TMS1 supports prere- tial history S is a linear extension of H if S ≡ H and lease. Then by Definition 3, there exists some TMS1 history the order of transactions in S preserves the partial order H s.t. T , T ∈ H and there is a prefix P of H s.t. op = PO PO i j ≺ , i.e., ≺ ⊆≺ . Then, the causal past C (H , T ) of S i H H w (x)v → ok ∈ P|T , op = r (x) → v ∈ P|T , and T is i i i j j i some transaction T in some history H is such a history that live in H. This implies that inv (tryC )/ ∈ P↑res (v)|T .This i j includes T (i.e. H |T ⊆ C (H , T ) and includes every T (i.e. i i i j c c PO means that T ∈ / T and therefore is not in any T ⊆ T H H H H |T ⊆ C (H , T ) s.t. T ≺ T . j i j i or, by extension, is not in any σ ∈ ser(T , ≺ ). Therefore, Definition 16 (Virtual World Consistency) History H is there is no op in ops(σ, res (v)), so, assuming unique writes, virtual world consistent iff its subhistory containing all com- op is not preceded by a write of v to x in ops(σ ·T , res (v))· mitted transactions is serializable and preserves real-time [r (x) → v]. Therefore, ops(σ · T , res (v)) ·[r (x) → v] is j j j order, and for each aborted transaction T there exists a linear not legal, which contradicts Definition 15. extension S of its causal past C (H , T ) that is legal. Since both Definitions 4 and 5 require prerelease support, VWC allows limited support for prerelease as follows. then: Lemma 14 VWC supports prerelease. Corollary 13 TMS1 does not support overwriting. Corollary 14 TMS1 does not support aborting prerelease. Proof Let H be a transactional history as shown in Fig. 6. Here, T performs two operations on x and one on y, while TMS2 is a stricter, but more intuitive version of TMS1. T reads x. The sequential witness history of H is S = Since the authors show in [13] that TMS2 is strictly stronger H |T · H |T wherein both transactions are committed and i j than TMS1 (TMS2 implements TMS1), the conclusions trivially legal. Thus H is VWC. Since, by Definition 2, T above equally apply to TMS2. Hence, from Lemma 13: prereleases a variable in H, then, by Definition 3, VWC sup- Corollary 15 TMS2 does not support prerelease. ports prerelease. Corollary 16 TMS2 does not support overwriting. Lemma 15 VWC does not support overwriting. Proof Since VWC requires that aborting transactions view a Corollary 17 TMS2 does not support aborting prerelease. legal causal past, then, if a transaction reading x is aborted, it must read a legal (i.e. “final”) value of x. Thus, let us consider 4.10 Virtual world consistency some history H (with unique writes) where some T writes value v to x and prereleases x, and some T reads v from x The requirements of opacity, while very important in the j (so T reads from T ). context of TM’s ability to execute any operation transaction- j i ally, can often be excessively stringent. On the other hand (a) If T writes some value v to x after releasing it, and T serializability is considered too weak for many TM applica- i j commits, then T is not legal in any sequential witness tions. Thus, a weaker TM consistency condition called virtual j world consistency (VWC) was introduced in [23,24]. history S of H because there is another write operation PO Let us first define a partial order ≺ on the set of all trans- execution in S writing v to x between a write writing PO actions in H. Given two transactions T , T ∈ H, T ≺ T v to x and a read on x returning v, and therefore H does i j i j if: not satisfy VWC. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 279 (b) If T writes some value v to x after releasing it, and T i j aborts, then the causal past C (H , T ) contains T , and j i T is illegal in C (H , T ), because there is another write j j operation execution writing v to x between a write writ- ing v to x and a read on x returning v,so C (H , T ) is not Fig. 7 A live opaque history with prerelease legal. Thus, H does not satisfy VWC. Let H |(T , r ) be the longest subsequence of H |T contain- Therefore, any history H containing T , such that T prere- i i i i ing only read operation executions (possibly pending), with leases x and modifies it after release does not satisfy VWC. the exclusion of the last read operation if its response event Hence, by Definition 4, VWC does not support overwriting. is A .Let H |(T , gr ) be a subsequence of H |(T , r ) that con- i i i Lemma 16 VWC does not support aborting prerelease tains only non-local read operation executions. Let T be a transaction that invokes the same transactional operations as Proof Given a history H that satisfies VWC and a transac- those invoked in [start → ok ]· H |(T , r ) ·[inv (tryC )] if i i i tion T ∈ H that prereleases variable x in H, let us assume gr H |(T , r ) = ∅,or ∅ otherwise. Let T be a transaction that for the sake of contradiction that T eventually aborts. By invokes the same transactional operations as those invoked in Definition 2, there is some T in H that reads from T .If T j i i [start → ok ]· H |(T , gr)·[tryC → C ] if H |(T , gr) = ∅, i i i i i eventually aborts, then T reads from an aborted transaction. or ∅ otherwise. Given a history H, a transaction T ∈ H, and a complete (a) If T eventually aborts, then its causal past C (H , T ) j j local operation execution op = r (x) → v,wesay thelat- does not contain aborted transaction T and is, therefore, ter’s response event res (v) is legal if the last preceding write trivially illegal. Hence H does not satisfy VWC, which operation in H |T writes v to x. We say sequential history S is a contradiction. justifies the serializability of history H when there exists a (b) If T eventually commits, then the sequential witness his- history H that is a subsequence of H s.t. H only contains tory is also illegal. Hence H does not satisfy VWC, which invocation and response events issued and received by trans- is a contradiction. actions committed in H, and S is a legal history equivalent to H . Therefore, if T eventually aborts, H does not satisfy VWC, which is a contradiction. Thus, since a VWC history cannot Definition 17 (Live Opacity) A history H is live opaque iff, contain an abortable transaction that prereleases a variable, there exists a sequential history S that preserves the real time by Definition 5, VWC does not support aborting prerelease. order of H and justifies that H is serializable and all of the following hold: While VWC supports prerelease, there are severe limi- tations to this capability. That is, VWC does not allow a (a) We can extend history S to get a sequential history S such that: transaction that prereleased variables to subsequently abort for any reason. In addition, VWC places a requirement on gr – for each transaction T ∈ H s.t. T ∈ / S, T ∈ S , i i transactions to execute all read operations before executing –if < is a partial order induced by the real time order any of its writes. This places severe practical limitations on of S in such a way that for each transaction T ∈ H how programmers write transactional code. s.t. T ∈ / S we replace each instance of T in the set i i of pairs that constitute the real time order relation of 4.11 Live opacity gr H with transaction T , then S respects <, – S is legal. Live opacity was introduced in [14] as part of a set of con- (b) For each transaction T ∈ H s.t. T ∈ / S and for each sistency conditions and safety properties that were meant to i i gr regulate the ability of transactions to read from live trans- operation op in T that is not in T , the response for op i i is legal. actions. The work analyzes a number of properties and for each one presents a commit oriented variant that forbids pre- Live opacity is a variant of opacity specifically introduced release and a live variant that allows it. Here, we concentrate on live opacity, since it best fits alongside the other proper- to allow prerelease, but only for non-aborting transactions. We show this below. ties presented here, however our conclusions will apply to the remainder of live properties. Intuitively, live opacity works Lemma 17 Live opacity supports prerelease. by removing all write operations and local read operations from uncommitted transactions in a history and checking if Proof Let history H be that represented in Fig. 7. Since there the resulting history is opaque. is a transaction T ∈ H that writes 1 to x and a transaction T i j 123 280 K. Siek, P. T. Wojciechowski that reads 1 from x before T commits, then there is a prefix Lemma 19 Live opacity does not support aborting prere- P of H that meets Definition 2. Therefore T prereleases x lease. in H. Proof For the sake of contradiction, let us assume that there Let S be a sequential history s.t. S = H |T · H |T . Since i j is a history (with unique writes) H that is live opaque and, the real-time order of H is ∅, then, trivially, S preserves the from Definition 5, contains some transaction T that writes real-time order of H. Since Vis(S, T ) contains only H |T i i value v to some variable x and releases x and subsequently and therefore only a single write operation execution and no aborts in H. reads, then it is legal and T in S is legal in S. Furthermore, Let S be any sequential history that justifies the serializ- Vis(S, T ) is such that Vis(S, T ) = H |T · H |T and contains j j i j ability of H, and let S be any sequential extension of S in a read operation r (x) →1 preceded by the only write opera- accordance to Definition 17. Since T aborts in H, then it is tion w (x)1 → ok ,so Vis(S, T ) is legal, and, consequently, i i j gr gr not in S, and therefore it is replaced in S by T . Since T i i T in S is legal in S. Thus, all transactions in S are legal in does not contain any write operation executions, there is no S,so H is serializable. write operation execution writing v to x in S , by definition. Let S be a sequential history that extends S in accordance Since T prereleased x in H there is a transaction T in H i j to Definition 17. Since there are no transactions in S that are that executes a read operation reading v from x and the same not in S, then S = S. Thus, since every transaction in S is read operation is in S . But since there is no write operation legal in S, then every transaction in S is legal in S . Trivially, execution writing v to x in S , no transaction containing a S also preserves the real time order of S. Therefore, the read operation execution reading v from x can be legal in S . condition Definition 17a is met. Since there are no local read Thus, H is not live opaque, which is a contradiction. operations in S, then condition Definition 17b is trivially met Therefore H cannot be simultaneously live opaque and as well. Therefore, H is live opaque. contain a transaction with prerelease that aborts. Since H is both live opaque and contains a transaction that prereleases a variable, then the lemma holds. In addition, note that, if some transaction T in some history H reads from a live transaction T and T is itself k i Lemma 18 Live opacity does not support overwriting. live, then, according to live opacity, there cannot be any transaction T that reads from T . This is because if T is j i i gr Proof For the sake of contradiction, let us assume that there replaced in S with T , then whatever value T reads from gr gr T will not be written by T , so the read in T (or T )may is a history (with unique writes) H that is live opaque and, i j i j from Definition 4, contains some transaction T that writes not be legal. Transactions which prerelease are already not allowed to abort, so we consider this additional restriction value v to some variable x and prereleases x and subsequently executes another write operation writing v to x where the to be overstrict. Transactions that read from live transactions second write follows a read operation executed by transaction will not experience inconsistent views regardless of whether T reading v from x. that live transaction reads only from committed transactions Since H is live opaque there exists a sequential history or whether it reads from some yet another live transaction— S that justifies the serializability of H. There cannot exist all such live transactions must eventually commit. Therefore, a sequential history S where T reads from x between two it is not necessary for live opacity to preclude this scenario. Nevertheless, live opacity does preclude it. writes to x executed by T , because there cannot exist a legal Vis(S, T ),so T would not be legal in S. Therefore, T must j j j 4.12 Elastic opacity be aborted in H and therefore T is not in any sequential history S that justifies the serializability of H. Elastic opacity is a safety property based on opacity, that Since T is in H but not in S, then given any sequen- tial extension S of S in accordance to Definition 17, T is was introduced to describe the safety guarantees of elastic gr replaced in S by T which reads v from x and finally com- transactions [15]. The property allows to relax the atomicity mits. However, since the write operation execution writing v requirement of transactions to allow each of them to execute to x in T is followed in S |T by another write operation exe- as a series of smaller transactions. i i gr cution that writes v to x, then there cannot exist a Vis(S , T ) An elastic transaction T is split into a sequence of sub- gr histories called a cut denoted C (H ), where each subhistory that is legal. Thus T in S cannot be legal in S , which con- i represents a “subtransaction.” In brief, a cut that contains tradicts Definition 17a. Thus, H is not live opaque, which is more than one operation execution is well-formed if all sub- a contradiction. histories are longer than one operation execution, all the write Therefore H cannot simultaneously be live opaque and operations within the same transaction are in the same sub- contain a prereleasing transaction and overwriting. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 281 Fig. 8 An elastic opaque history with prerelease Fig. 9 An elastic opaque history with prerelease after applying a cutting function history, and the first operation execution on any variable in be a cut of subhistory H |T , such that: every subhistory is not a write operation, except possibly in the first subhistory. A well-formed cut of some transaction T C (H ) = start → ok , r (y) →0, i i i i is consistent in some history H, if given any two operation executions op and op on x in any subhistories of the cut, no w (x)1 →ok , tryC → C , i i i i i i transaction T (i = j) executes a write operation op on x s.t. start → ok , r (x) →1, i i i op ≺ op ≺ op . In addition, given any two operation H H i j executions op and op on x, y respectively, no two transac- r (y) →0, tryC → C . i i i tions T , T (l = i, k = i) execute writes op on x and op k l k l on y, s.t. op ≺ op ≺ op and op ≺ op ≺ op .A H H H H i k i l i i All subhistories of C (H ) are longer than one operation, cutting function f takes a history H as an argument and pro- all the writes are in the first subhistory, and no subhistory duces a new history H where for each transaction T ∈ H f i starts with a write, so C (H ) is well-formed. Since there are declared as elastic, T is replaced in H with the transac- i f no write operations outside of T , then it follows that C (H ) i i tions resulting from the cut C (H ) of T . If some transaction i i is a consistent cut in H.Let f be any cutting function such is committed (aborted) in H, then all transactions resulting that it cuts T according to C (H ), in which case f (H ) is i i C from its cut are committed (aborted) in f (H ). Then, elastic defined as in Fig. 9.Let S be a sequential history s.t. S = opacity is defined as follows: f (H )|T · f (H )|T · f (H )|T . Since T precedes T C i C j C i i i in S as well as in f (H ), and all other transactions are not Definition 18 (Elastic Opacity) History H is elastic opaque real time ordered, S preserves the real time order of f (H ). iff there exists a cutting function f that replaces each elastic C Trivially, each transaction in S is legal in S. Thus, f (H ) is transaction T in H with its consistent cut C (H ), such that opaque by Definition 12, and in effect H is elastic opaque i i history f (H ) is opaque. C by Definition 18. Since in H transaction T reads x from T j i while T is live, then, by Definition 2, T prereleases x in H. i i Hence, since H is elastic opaque, elastic opacity supports Note that the authors demonstrate in [15] that if, for some prerelease, by Definition 3. initial history H, the history f (H ) is opaque, then it does not necessarily mean that H is serializable. Thus, elastic opacity Lemma 21 Elastic opacity does not support overwriting. is not strictly stronger than serializability. Proof For the sake of contradiction, let us assume that there is Elastic opacity (Definition 18) checks the validity of a an elastic opaque history H, s.t. transaction T writes value v history, not by validating the consistency of transactions, but to some variable x and prereleases it in H. Furthermore, let us of fragments of transactions. Hence, elastic opacity supports assume that there is overwriting, so after some transaction T prerelease. A formal demonstration follows. reads v from x, T writes u to x. Since only elastic transactions can prerelease in elastic opaque histories, and T prereleases Lemma 20 Elastic opacity supports prerelease. a variable, T is necessarily elastic. Thus, in any f (H ) T is i C i replaced by a cut C (H ). Proof Let H be a transactional history with unique writes as The two writes on x in T are either a) in two different shown in Fig. 8.Let T be an elastic transaction. Let C (H ) subhistories in C (H ), or b) in the same subhistory in C (H ). i i i i 123 282 K. Siek, P. T. Wojciechowski Since the definition of a consistent cut requires all writes on a In addition, elastic transactions, i.e. transactions described single variable to be within one subhistory of the cut, then in by elastic opacity, were proposed as an alternative to tra- case (a), C (H ) is inconsistent. Since by Definition 18 elastic ditional transactions for implementing search structures. opaque histories are created using consistent cuts, then H is However, we submit that the restrictions placed on the com- not elastic opaque, which is a contradiction. position of elastic transactions and the need for transactions In the case of (b), let us say that both writes are in a sub- with prerelease to be non-aborting put an unnecessary burden history that is converted into transaction T in f (H ). Since on general-purpose TM. In particular, for a cut to be well- i C T prereleases x, then by Definition 2, there is a transaction formed, it is necessary that all writes on the same variable are T in f (H ) which executes a read on x reading the value executed in the same subtransaction, and that no subtransac- j C written by T in f (H ). Since we assume overwriting, the tion starts with a write, which severely limits how prerelease read operation on x in T reads the value written by the first can be used and precludes scenarios that are nevertheless of the two writes in T and does so before the other write on intuitively correct. x is performed within C (i ). Then, in any sequential history S equivalent to f (H ) either T ≺ T or T ≺ T .In C j S i i S j the former case T in S is not legal in S, since the read on x 4.13 Summary that yields value v will not be preceded by any operation that writes v to x in any possible Vis(S, T ). In the latter case T In Table 1 we present a summary of the properties discussed j j in S is also not legal in S, since there will be a write oper- in this section. The table informs whether a particular prop- ation writing u to x between the read on x that yields value erty is a database property or a TM property, and whether v and any operation that writes v to x in Vis(S, T ). Since each of the properties satisfies the definitions for prerelease T in S is not legal in any S equivalent to f (H ), then, by support, overwriting support, and aborting prerelease sup- Definition 11, f (H ) is not final-state opaque, and hence, by port. Finally, the last column informs whether each property Definition 12, not opaque. In effect, by Definition 18, H is is at least as strong as serializability. not opaque, which is a contradiction. The survey of properties shows that, while there are many Thus, there cannot be an elastic opaque history H with safety properties for TM with a wide range of guarantees overwriting. they provide, with respect to prerelease they fall into three basic groups. Lemma 22 Elastic opacity does not support aborting prere- The first group consists of properties that allow prerelease lease. but do not prevent overwriting: serializability, commit order preservation, and recoverability. These properties do not reg- Proof For the sake of contradiction, let us assume that there ulate what can be seen by aborting transactions. In effect, is an elastic opaque history H s.t. transaction T prereleases they allow any dangerous scenario to occur with respect to some variable x in H and aborts. Since T prereleases a vari- prerelease, as long as the situation is resolved by aborting able then it writes v to x, and there is another T that executes offending transactions. As argued in [17], this is insufficient a read on x that returns v before T aborts. Since only elastic for TM in general, because operating on inconsistent state transactions can prerelease in elastic opaque histories, and T may lead to uncontrollable errors, including crashing the pro- prereleases a variable, T is necessarily elastic. If T aborts i i cess. in H, then all of the transactions resulting from its cut C (H ) The second group consists of properties that preclude the in f (H ) also abort (by construction of f (H )). Therefore, C C dangerous situations allowed by the first group. This group for any sequential history S equivalent to f (H ), there is no includes cascadelessness, strictness, rigorousness, opacity, subhistory H ∈ C (H ) s.t. H ⊆ Vis(S, T ), and in effect the i j markability, TMS1, and TMS2. The properties in this group read operation in T on x reading v is not preceded by a write forbid prerelease altogether, thus solving all related consis- operation writing v to x. Therefore, Vis(S, T ) is illegal, so T j j tency problems, but making them unusable in conjunction in S is not legal in S, and thus, by Definition 12 f (H ) is not with the prerelease technique. opaque. Since f (H ) is not opaque, then by Definition 18, The third group allows prerelease but precludes overwrit- H is not elastic opaque, which is a contradiction. ing and reading from aborting transactions. It includes live Elastic opacity supports prerelease, but, since it does not opacity, elastic opacity, and VWC. These properties seem to guarantee serializability (as shown in [15]), we consider it to provide a reasonable middle ground between allowing pre- be a relatively weak property. This is contrary to our premise release and eliminating inconsistent views. However, these of finding a property that allows prerelease and provides properties forbid transactions to prerelease and abort. As such stronger guarantees than serializability. It also makes elas- they can be useful only for TM operating in the commit-only tic opacity unintuitive to programmers, and therefore less model, or in TM systems where transactions that prerelease than practical. become irrevocable. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 283 Table 1 Summary of property prerelease support: Definition 3 is prerelease support, Definition 4 is overwriting support, and Definition 5 is aborting prerelease support Property Application Definition 3 Definition 4 Definition 5 ⊆ Serializable Serializability Database, TM Commit order preservation Database × Recoverability Database × Cascadelessness Database ×××× Strictness Database ××× Rigorousness Database ××× Opacity TM ××× Markability TM ××× TMS1 TM ××× TMS2 TM ××× Virtual world consistency TM ×× Live opacity TM ×× Elastic opacity TM ××× On the other hand the commit-only model limits the appli- In summary, properties from the first group are not ade- cability of such TMs in certain contexts, since arbitrary aborts quate for any TM and those from the second group do not can be a necessary prerequisite for some applications. For allow any form of prerelease. The third group imposes an instance, aborts are a necessary part of recovery mechanisms overstrict requirement that transactions which prerelease be that bring the TM system to a consistent state as a result of a irrevocable. None of the properties provide a satisfactory, partial failure. Another example is a deadlock recovery sys- strong safety property that could be used for a TM with pre- tem, which aborts transactions to eliminate wait dependency release in general. Thus, guarantees given by a TM where cycles. Furthermore, TM systems that provide the program- prerelease is a necessary component, but where transactions mer access to arbitrary aborts are more expressive. That cannot be prevented from aborting, cannot be adequately is, there are situations where the programmer may want to expressed with the existing properties. withdraw any changes made by a transaction mid-execution. Reverting changes ad hoc detracts from the readability of the code, and it is usually less efficient. The problem becomes 5 Last-use opacity magnified in distributed TM, where performing an ad hoc abort and compensation remotely usually comes at a price of We present last-use opacity, a new TM safety property that extra network communication overhead. Thus, for DTM and provides strong consistency guarantees and allows prerelease TM systems in the arbitrary abort model, live opacity and without compromising on the ability of transactions to abort. VWC are not useful. We present an intuition behind the basic concepts and the On the other hand, if transactions are allowed to abort in property itself first, followed by formal definitions. We then general, but not in the case of ones that prerelease variables, give examples of histories that fulfill or fail to fulfill the prop- then this results in additional complexity to a TM (see e.g., erty and finally discuss the guarantees the property gives. [27,45]). Moreover, in applications like distributed comput- ing, transaction aborts may be induced by external stimuli, 5.1 Intuitions and definitions so it can be completely impossible to prevent transactions from aborting [41]. The idea of last-use opacity hinges on two basic concepts: In addition, some of those properties also have specific enforcing transactional restraint and on identifying the clos- problems that make them difficult to apply widely in practice. ing write operation execution on a given variable within the For instance, elastic opacity introduces unnecessary restric- code of individual transactions. tions on the order of operations within a transaction, while simultaneously diverging from the minimal standard set by serializability. Meanwhile, live opacity arbitrarily precludes transactions that read prereleased variables from prereleasing themselves. 123 284 K. Siek, P. T. Wojciechowski 5.1.1 Restraint Informally, restraint specifies what actions a transaction is allowed to take after it becomes clear that it has viewed incon- sistent data. A transaction that reads from a live transaction is, after all, doomed to abort as soon as that other transaction aborts. A transaction that views the state of an aborted trans- Fig. 10 Transactional program with a closing write action clearly should not be able to commit, but should it be allowed to write or read before it eventually aborts? While in theory some systems may allow reading or writing within such doomed transactions, the authors are not aware of any the variable will be modified further between a write oper- systems that do so in practice. This is because any action ation and the eventual commit attempt. So, in essence, a undertaken after the transaction becomes doomed is at best closing write on some variable is such, that the transaction unnecessary (destined to be rolled back) and at worst have which executed it will not subsequently execute another write a detrimental or unexpected effect on the execution of the operation on the same variable in any possible extension of program. Restraint excludes such effects by requiring that the history. What is possible is determined by the program doomed transactions only perform operations that lead to an that is being evaluated to create that history. Knowing the abort. program, it is possible to infer (to an extent) what opera- Formally, given a history H containing two transactions tions a particular transaction will execute. Hence, knowing T , T ∈ H, T depends on T iff T reads from T or there the program, we can determine whether a particular opera- i j i j i j exists T ∈ H such that T reads from T and T depends on tion on some variable is the last possible such operation on k k j i T . that variable within a given transaction. Thus, we can deter- Given history H, a transaction T ∈ H, and an event mine whether a given operation is the closing write operation e ∈ H,let after (T , e) be the longest subsequence of H |T in a transaction. i i containing only such events that follow e in H. In addition, in a system containing invariants, some vari- ables must be considered in groups, rather than individually. Definition 19 (Restraint) History H is restrained if given When several variables are involved in an invariant, we can- any two transactions T , T ∈ H s.t. T depends on T ,if i j i j not say that the value of one of them is “settled” until all of T aborts (ie. res (A) ∈ H |T ) then after (T , res (A)) is j j i j j them are. Thus, a closing write on any variable which tangled either: an invariant is the latest write in a given transaction on any of the variables involved in that invariant. (a) an empty sequence, Take, for instance, the program in Fig. 10, where subpro- (b) a sequence containing only res (A), gram P spawns transaction T , and P spawns T . Let us i 1 1 2 2 (c) a sequence containing only a single invocation, assume that initially x and y are set to 0. Depending on the (d) a sequence containing only a single invocation followed semantics of the TM, as these subprograms interweave dur- by res (A). ing the execution, a number of histories can be produced. We can divide all of among them into two cases. In the first case In itself, restraint does not defend a transaction against T writes 1 to y in line 11 (in P ) and this value is then read 2 2 executing local, non-transactional operations using data orig- by T in line 4 (in P ). As a consequence, T will execute 1 1 1 inating from inconsistent views, which may potentially lead the write operation in line 5. The second case assumes that to unanticipated operations such as going into infinite loops T reads 0 in line 4 (e.g., because T executed line 11 much 1 2 and dividing by zero (we will discuss this issue in Sect. 5.4). later). In this case, T will not execute the write operation in Since these operations typically cannot be controlled by the line 5. We can see, however, that in either of the above cases, TM system, it would be impractical to have them restricted. once T executes the write to x in line 5, then no further writes Instead, we introduce another concept called closing writes to x will follow in T in any conceivable history. Thus, the that ensures the data leaking via inconsistent view is safe to write operation execution generated by line 5 is the closing use in local operations. write on x in T . On the other hand, the write operation exe- cution generated by line 3 of P is never the closing write 5.1.2 Closing writes on x in T , because there exists a conceivable history where another write operation execution will appear (i.e., once line Informally, a closing write describes a point in time after 5 is evaluated). This is true even in the second of the cases, which a transaction has “settled” on the state of some vari- because line 5 can be executed in potentia, even if it is not able. The biggest component of this consideration is whether executed de facto. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 285 Given program P and a set of processes Π executing T as if it had attempted to commit. Thus, if a transaction P, since different interleavings of Π cause an execution executes its closing write on some variable, we say that the P,Π E (P,Π) to produce different histories, then let H be the transaction decided on x. set of all possible histories that can be produced by E (P,Π), P,Π P,Π Definition 22 (Transaction Decided on x) Given a program i.e., H is the largest possible set s.t. H ={H | H | P, a set of processes Π and a history H s.t. H | E (P,Π),we E (P,Π)}. say transaction T ∈ H decided on variable x in H iff H |T i i Definition 20 (Closing Write Invocation) Given a program contains a complete write operation execution w (x)v →ok i i P, a set of invariants I, a set of processes Π executing P, and that is the closing write on x. a history H s.t. H | E (P,Π), an invocation inv (w(y)v) on some variable y by transaction T in H is the closing 5.1.3 Last-use opacity write invocation on some variable x by transaction T in H, x P,Π if y ∈ I and for any history H ∈ H for which H and Last use opacity uses the concepts of restraint and closing H have a common prefix P ending with inv (w(y)v) i.e., writes to dictate when a transaction can read from another P = P ·[inv (w(y)v)], H = P · R, and H = P · R , there transaction. is no write operation invocation inv = inv (w(z)u) for any Intuitively, given any two transactions, T and T , last-use i i j variable z ∈ I , s.t. inv (w(y)v) precedes inv in H |T . opacity allows T to read variable x from T if the latter is i i i j either committed or commit-pending, or, if T is live and it Definition 21 (Closing Write) Given a program P,asetof already executed its closing write on x. This has the benefit of processes Π executing P and a history H s.t. H | E (P,Π), allowing prerelease while excluding overwriting completely. an operation execution is the closing write on some variable Simultaneously all transactions must be restrained to x by transaction T in H if it comprises of an invocation and avoid performing operations on data coming from inconsis- , and the invocation is the closing a response other than A tent views. This approach prevents most inconsistent views. write invocation on x by T in H. Inconsistent views can only occur when a transaction releases a variable after a closing write and subsequently aborts. Due We call a write invocation or operation that is not closing, to the prescribed finality of closing writes and due to the a non-closing write invocation or operation, and so on for restriction on using inconsistent data imposed by the defi- read invocations and operations. In transaction diagrams we nition of restrain we consider this situation to be benign in mark a closing write operation execution in some history as practice. We discuss the details of this and other implications . Note that an operation can be the ultimate operation of last-use opacity after giving the formal definition. Specif- execution in some transaction, but still not fit the definition ically, we discuss the guarantees given by the property in of a closing operation execution. full in Sect. 5.3 and the implications of inconsistent views in What is considered a closing write depends on invariants Sect. 5.5, as well as ways of mitigating them. We compare the associated with a given system. It is worth exploring how strength of last-use opacity with other properties in Sect. 5.6. specific examples of invariant sets impact the definition of Givensomehistory H,let T be a set of transactions s.t. closing write invocations. Let us first consider a system with ∅ ˆ T ∈ T iff there is some variable x s.t. T decided on x i i an empty set of invariants I . If a system declares no invari- in H. Given any T ∈ H,a decided transaction subhistory, ants, then for any variable x and any transaction T ,the set i x ˆ denoted H |T , is the longest subsequence of H |T s.t.: i i I contains only x. The same is true if the system has only invariants whose domains are singletons I . In both cases the (a) H |T contains start → ok , and closing write invocation on a variable will simply be the last i i i (b) for any variable x,if T decided on x in H, then H |T possible write invocation on that variable in a given trans- i i action. Alternatively, in I , where all variables are involved contains (H |T )|x. in an invariant in all transactions, I is the set of all vari- ables, so the closing write on all variables in a transaction In addition, a decided transaction subhistory completion, ˘ ˘ ˆ will be any last possible write invocation on any variable in denoted H |T , is a sequence s.t. H |T = H |T · tryC → C . i i i i that transaction. The definition of opacity includes a definition of Vis,a Note that once any transaction T completes executing its subhistory visible to a specific transaction. Last-use Opacity closing write on some variable x, it is certain that no further includes a similar definition: LVis. The definition of Vis spec- modifications to that variable are intended by the programmer ifies that a transaction may view the operations performed as part of T . This means, from the perspective of T (and by itself or other committed transactions. LVis makes the i i assuming no other transaction modifies x) the state of x would same requirement of committed transactions, but uncom- be the same at the time of the closing write as if the transaction mitted transactions have a choice to either view operations attempted to commit. Hence, with respect to x, we can treat performed in some decided transaction subhistory, or not. 123 286 K. Siek, P. T. Wojciechowski This freedom assures that transactions are not forced to read from doomed or aborting transactions and it is further illus- trated in Sect. 5.2.4. Formally, given a sequential history S s.t. S ≡ H, LVis(S, T ) is the longest subhistory of S, s.t. for each T ∈ S: Fig. 11 Prerelease on closing write—last-use–opaque history (a) if i = j or both T is committed in S and T ≺ T , then j j S i S|T ⊆ LVis(S, T ), j i (b) if T is not committed in S but T ∈ T and T ≺ T , j j j S i and it is not true that T ≺ T , then either S|T ⊆ j H i j LVis(S, T ) or not. Fig. 12 Prerelease to an aborting transaction—last-use–opaque history Given a sequential history S and a transaction T ∈ S,we then say that transaction T is last-use legal in S if LVis(S, T ) i i is legal. Note that if S is legal, then it is also last-use legal (see appendix for proof). Definition 23 (Final-state Last-use Opacity) A finite history H is final-state last-use opaque if, and only if, there exists a sequential history S equivalent to Compl(H ) s.t., Fig. 13 Prerelease with two aborting transactions—last-use–opaque history (a) S preserves the real-time order of H, (b) every transaction in S that is committed in S is legal in 5.2.1 Prerelease on closing write S, (c) every transaction in S that is not committed in S is last-use The example in Fig. 11 shows T executing a write on x once legal in S, and prereleasing x to T . We assume that the program gen- (d) H is restrained. erating the history is such, that the write operation executed by T is the closing write operation execution on x. The his- Definition 24 (Last-use Opacity) A history H is last-use tory is intuitively correct, since both transactions commit, opaque if, and only if, every finite prefix of H is final-state and T reads a value written by T . On the formal side, since j i last-use opaque. both transactions are committed in this history, the equiva- lent sequential history would consist of all the events in T Theorem 1 Last-use opacity is a safety property. followed by the events in T and both transactions would be legal, since T writes a legal value to x and T reads the i j Proof By Definition 24, last-use opacity is trivially prefix- last value written by T to x. Thus, the history is final-state closed. last-use opaque. Given H that is an infinite limit of any sequence of finite Since last-use opacity requires prefix closeness, then all histories H , H ,...,s.t every H in the sequence is last- 0 1 h prefixes of the history in Fig. 11 also need to be final-state use–opaque and every H is a prefix of H , since each h h+1 last-use opaque. We present only two of the interesting pre- prefix H of H is last-use–opaque, then, by extension, every h L fixes, since the remainder are either similar or trivial. The first prefix of H is also final-state last-use opaque, so, by Defi- interesting prefix is created by removing the commit oper- nition 24, H is last-use–opaque. Hence, last-use opacity is ation execution from T , which means T is aborted in any j j limit-closed. completion of the history. We show such a completion in Fig. Since last-use opacity is both prefix-closed and limit- 12. Still, T writes a legal value to x and T reads the last value i j closed, then, by Definition 1, it is a safety property. written by T to x, so that prefix is also final-state last-use opaque. Another interesting prefix is created by removing the 5.2 Examples commit operation executions from both transactions. Then, in the completion of the history both transactions are aborted, as In order to aid understanding of the property we present in Fig. 13. Then, in an equivalent sequential history T would examples of last-use opaque histories. These are contrasted read a value written by an aborted transaction. In order to by examples of histories that are not last-use opaque. We show legality of a committed transaction, we use the subhis- discuss the examples below. tory denoted Vis, which does not contain any transactions that 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 287 Fig. 14 Prerelease before closing write—not last-use–opaque Fig. 15 Prerelease with two aborting transactions before closing write—not last-use–opaque were not committed in the history from which it was derived. Thus, if T were committed, it would not be legal, since its Vis would not contain a write operation execution writing the value the transaction actually read. However, since T Fig. 16 Prerelease to a prematurely aborting transaction—last-use– is aborted, the definition of final-state last-use opacity only opaque requires that LVis rather than Vis be legal, and LVis can contain operation executions on particular variables from an aborted transaction under the condition that the transaction already executed its closing write on the variables in question. Since, in the example T executed its closing write on x, then this write will be included in LVis for T ,so T will be last-use j j Fig. 17 Commit order not respected—not last-use–opaque legal. In consequence the prefix is also final-state last-use opaque. Indeed, all prefixes of example Fig. 11 are final- state last-use opaque, so the example is last-use opaque, and, by extension, so are the examples in Figs. 12 and 13. Fig. 18 Reverse commit order in writer transactions—last-use–opaque 5.2.2 Prerelease on non-closing write Contrast the example in Fig. 11 with the one in Fig. 14.The 5.2.3 Recoverability histories presented in both are identical, with the exception that the write operation in Fig. 11 is considered to be the The examples in Figs. 16 and 17, show that recoverability closing operation execution, while in Fig. 14 it is not. The is required, i.e., transactions must commit in order. Last- difference would stem from differences in the programs that use opacity of the example in Fig. 16 is analogous to the produced these histories. For instance, the program produc- one in Fig. 12, since their equivalent sequential histories are ing the history in Fig. 14 could conditionally execute another identical, as are the sequential histories equivalent to their operation on x, so, even though that condition was not met in prefixes. Furthermore, intuitively, if T reads a value of a this history, the potential of another write on x means that the variable prereleased by T and aborts before T commits, this i i existing write cannot be considered a closing write operation is correct behavior. On the other hand, the history in Fig. 17 execution. The consequence of this is that while the example is not last-use opaque, even though it is final-state last-use itself is final-state last-use opaque, one of its prefixes is not, so opaque (by analogy to Fig. 11). More specifically, a prefix of the history is not last-use opaque. We would reach the same the history where the commit operation execution is removed conclusion if T would abort. The offending prefix is created from T is not final-state last-use opaque. This is because j i by removing commit operations in both transactions, so both a completion will require that T be aborted. By definition, transactions would abort in any completion, as in Fig. 15. operations from aborted operations cannot be included in Vis, Here, since T does not execute the closing write operation so operations executed by T are not going to be included in i i on x, then the write operation would not be included in LVis Vis for T . Since T is committed, then its Vis must be legal, j j for T , so the value read by T could not be justified. Thus, but it is not, because the read operation reading 1 will not be j j T is not legal in that history, and, therefore, the history in preceded by any writes in Vis. Since the prefix contains an Fig. 15 is not final-state last-use opaque (so also not last-use illegal transaction, then it is not final-state last-use opaque, opaque). Fig. 15 represents the completion of a prefix of the and thus, the history in Fig. 17 is not last-use opaque. history in Fig. 14,soFig. 15 not being final-state last-use On the other hand, the example in Fig. 18 shows that the opaque, means that Fig. 14 is not last-use opaque. commitment order is not required for all conflicting transac- 123 288 K. Siek, P. T. Wojciechowski Fig. 19 Freedom to read from or ignore an aborted transaction—last-use–opaque tions, just those with a reads-from relation. Here, the example is analogous to Fig. 17,but T does not read from T .This j i means that T ’s LVis and Vis will be legal regardless of whether T ’s operations are included or excluded. Then, given a sequential history equivalent to the example, where T pre- Fig. 20 Prerelease with overwriting—not last-use–opaque cedes T , both T and T in such a history will be legal. Hence j i j the history is final-state last-use opaque. Then, in all prefixes of the history T is aborted in the completion, whereas T i j may be either committed or aborted. If T is committed, then T will not be included in T ’s Vis, but this does not make Vis i j illegal, as we pointed out earlier. Similarly, if T is aborted, then T may or may not be included in T ’s LVis, but this is i j Fig. 21 Dependency cycle—not last-use–opaque immaterial with respect to T ’s LVis being legal. Hence all the prefixes will be final-state last-use opaque as well, and, in effect, the example is last-use opaque. write operation writing 2 to x also preceding the read. Thus, 5.2.4 Consistent values in all cases T is not legal, and the history is neither final-state last-use opaque, nor last-use opaque. The example in Fig. 19 shows that a transaction is allowed to read from a transaction that eventually aborts, or ignore that transaction, because of the freedom left within the definition 5.2.6 Dependency cycle of LVis. I.e., transaction T is concurrent to T ,but T follows j i k T in real time. T executes a closing write on x,so T is Finally, Fig. 21 shows an example of a cyclic dependency, i i j allowed to include the write operation in its LVis. Since T where T reads x from T , and subsequently T reads y from j i i sees the value written to x by that write, T includes the write T . Both writes in the history are closing writes. This example j j in LVis. On the other hand, T cannot include T ’s write in has unfinished transactions, which are thus aborted in any k i LVis, since T aborted before T even started, so the write possible completion of this history. There are two possible i k should not be visible to T . On the other hand T is allowed sequential histories equivalent to that completion: one where k k to include T in its LVis. T should not do so, however, since it T precedes T and one where T precedes T . In the former j k i j j i ignores T as well as T (which makes sense as T is doomed case, LVis of T does not contain any operations from T , j i j i j to abort). Hence T reads the value of x to be 0. If T is because T follows T . Thus, there is no write operation on k j j i included in T ’s LVis, reading 0 would be incorrect. Hence, y preceding a read on y returning 1 in T ’s LVis, which does k i the definition of LVis allows T to be arbitrarily excluded. In not conform to the sequential specification, so T ’s LVis is j i effect all three transactions are correct (so long as T does not legal. Hence, T is not legal in that scenario. The former j i not eventually commit). case is analogous: T ’s LVis will not contain a write operation from T , because T follows T . Therefore T ’s LVis contains i i j j 5.2.5 Overwriting a read on x that returns 1, which is not preceded by any write on x, which causes the sequence not to conform to the Figure 20 shows an example of overwriting, which is not last- sequential specification and renders the transaction not legal. use opaque, since there is no equivalent sequential history Since either case contains a transaction that is not legal, then where the write operation in T writing 1 to x would precede that history is not final-state last-use opaque, and therefore the read operation in T reading 1 from x without the other not last-use opaque. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 289 5.3 Guarantees P is not last-use opaque and thus, by Definition 24, H is not last-use opaque, which is a contradiction. Last-use opacity gives the programmer the following guar- Last-use opacity does not preserve commitment order as antees. defined in Definition 7 (see e.g., Fig. 18), but we consider recoverability sufficient for TM. Note that strong properties 5.3.1 Serializability like opacity also deal with commitment order only to the extent of recoverability. If a transaction commits, then the value it reads can be explained by operations executed by preceding or concurrent 5.3.4 Precluding overwriting transactions. This guarantees that a transaction that views inconsistent state will not commit. If transaction T reads the value of some variable written by Lemma 23 (Serializability) Every last-use–opaque history is transaction T , then T will never subsequently modify that j j serializable. variable. Proof For the sake of contradiction let us assume that H is Lemma 26 (Precluding Overwriting) Last-use opacity does last-use–opaque and not serializable. Since H is last-use– not support overwriting. opaque, then from Definition 24 H is also final-state last-use opaque. Then, from Definition 23 there exists a completion Proof For the sake of contradiction let us assume that there H = Compl(H ) such that there is a sequential history S exists H that is a last-use–opaque history with overwriting C H ˆ ˆ s.t. S ≡ H , S preserves the real-time order of H , and H C H C (and unique writes), i.e. (from Definition 4) there are trans- ˆ ˆ any committed transaction in S is legal in S . However, actions T and T s.t.: H H i j since H is not serializable, then from Definition 6 there does not exist a completion H = Compl(H ) such that there is C (a) T prereleases some variable x, ˆ ˆ a sequential history S s.t. S ≡ H , and any committed H H C (b) H |T contains w (x)v → ok and w (x)v → ok , s.t. the i i i i i ˆ ˆ transaction in S is legal in S . This contradicts the previous former precedes the latter in H |T , H H statement. (c) H |T contains r (x) → v that precedes w (x)v → ok in j j i i H . 5.3.2 Real-time order Since H is opaque, then there is a completion C = Successive transactions will not be rearranged to fit serializ- Compl(H ) and a sequential history S s.t. S ≡ Compl(H ), ability, so a correct history will agree with an external clock, S preserves the real-time order of H, and both T and T i j or an external order of events. in S are legal in S.In S, either T ≺ T or T ≺ T .In i S j j S i either case, any Vis(S, T ) or LVis(S, T ) by their definitions j j Lemma 24 (Real-time Order) Every last-use–opaque history will contain either the sequence of both w (x)v → ok and i i preserves real-time order. w (x)v →ok or neither of those write operation executions. i i In either case, r (x) → v will not be directly preceded by Proof Trivially from Definitions 24 and 23a. j w (x)v → ok among operations on x in either Vis(S, T ) or i i j LVis(S, T ). Therefore, T in S cannot be legal in S, which 5.3.3 Recoverability j j is a contradiction. If one transaction reads from another transaction, the former 5.3.5 Aborting prerelease will commit only after the latter commits. This guarantees that transactions commit in order. A transaction can prerelease some variable and subsequently Lemma 25 (Recoverability) Every last-use–opaque history abort. is recoverable. Lemma 27 (Aborting Prerelease) Last-use opacity supports Proof Let us assume that H is not recoverable. Then there aborting prerelease. must be some transactions T and T s.t. T reads from T i j j i and then T commits before T . Such a history will contain j i Proof Let H be the history depicted in Fig. 13. Here, T a prefix P where any completion will contain an aborted T prereleases x to T and subsequently aborts, which satisfies and a committed T , so for any equivalent sequential history Definition 5. Since T and T are both aborted in H, H has a i j ˆ ˆ ˆ S Vis(S , T ) will not contain S |T . Since T reads from H H j H i j completion C = Compl(H ) = H.Let S be a sequential his- T then such Vis(S , T ) will not be legal, so by Definition 23 tory s.t. S = H |T ·H |T . S vacuously preserves the real-time i H j i j 123 290 K. Siek, P. T. Wojciechowski order of H and trivially S ≡ H. Transaction T in S is last-use legal in S, because LVis(S, T ) = S|T —whose operations i i on x are limited to a single write operation execution—is within the sequential specification of x. Transaction T in S is also last-use legal in S, since LVis(S, T ) = H |T · S|T — j i j whose operations on x consist of w (x)v → ok followed i i Fig. 22 Inconsistent view examples with invariants by r (x) → v—is also within the sequential specification of x. Since both T and T in S are last-use legal in S, H i j is final-state last-use opaque. All prefixes of H are trivially also final-state last-use opaque (since either their completion is the same as H’s, they contain only a single write opera- tion execution on x, or contain no operation executions on variables), so H is last-use opaque. Fig. 23 Partial execution of P and P 5 6 5.4 Invariants operations involving assumptions about relationships among Invariants impact when a value can be read from a live trans- shared variables. This also still allows live transactions to action, so they define which inconsistent states are allowed expose values they write before committing, allowing other to be seen outside of a running transaction while still sat- transactions to parallelize with them for the duration of any isfying last-use opacity. By default we assume there are no local calculations or subsequent reads. However, the degree invariants (I ). This means that a variable written by some to which transactions are allowed to execute in parallel is live transaction can be read as soon as it can be determined much more limited than with an assumption of I or a more that a transaction will not perform any more writes on that tailored set of invariants. exact variable. This allows for more parallel executions, but In any case, the inconsistent views seen by last-use– the resulting inconsistent states may result in harmful oper- opaque transactions are limited to only to those, where ations. each transaction only ever exposes values it wrote that it For example, take the program in Fig. 22. The program- expected to commit with. But, in addition, if the assumptions mer silently assumes that x = y, but this assumption is not about relationships between variables are comprehensively part of formal requirements (that is, we still assume I ). expressed as a set of invariants, for any variables entangled in Nevertheless, any sequential execution of subprograms P such relationships, each transaction will only ever expose a and P will not yield errors, as the assumption is born out as variable if all related variables reach a state that the trans- postconditions of each transaction block. action planned to commit with. In this way, the exposed However, an interleaved execution in Fig. 23 would pro- inconsistent views are prevented from causing harm. duce an error. Here P executes transaction T and P 5 i 6 executes T . In this execution, the writer transaction T could j i 5.5 Inconsistent views be interleaved with the reader T in such a way that T reads j j the value of y from before T and the value of x written by Last-use opacity does not preclude transactions from abort- T . Since there is no other possible future write to x in T , i i ing after prereleasing a variable. As a consequence there the read does not break last-use opacity. But it does crash the may be instances of cascading aborts, which have varying program: If the value of just x is read from T , but not y,the implications on consistency depending on whether the TM values may be equal, leading P to end up dividing by zero. model allows transactions to abort programmatically. We dis- On the other hand, if the set of invariants includes an tinguish three cases of models and discuss them below. invariant representing x = y applied to (at least) T , then the write w (x)1 →ok is no longer closing. Instead, a write i i on y will be the closing write for both x and y in T , which 5.5.1 Commit-only model makes the history not last-use–opaque, and the crash is pre- cluded. This is safer, but removes some ability to parallelize Let us assume that transactions cannot arbitrarily abort, but transactions wherever invariants come into effect. only do so as a result of receiving an abort response to invok- Parameterizing a system with a set of explicit invari- ing a read or write operation, or while attempting to commit. ants may not always be practical. In that case, the designer In other words, there is no tryA operation in the transactional may use I as the default assumption. This means that a API, as per the commit-only transactional model. In that transaction will never allow reading from a live transac- case, since overwriting is not allowed, the transaction never tion until it finishes all of its writes. This precludes harmful reveals intermediate values of variables to other transactions. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 291 Fig. 25 Last-use opaque history with inconsistent view Fig. 24 Inconsistent view examples of these two transactions is clearly allowed by last-use opac- ity (assuming that the domain of x is Z). Thus, if the abort operation is available to the programmer the guarantee that This means that if a transaction prereleased a variable, then inconsistent views will not lead to unexpected effects is lost. the programmer did not intend to change the value of that Note that this is the case no matter if the transaction that variable. Neither did she intend to change the values of any has read from the programmatically aborted transaction will variables co-occurring with this one in an invariant. So, if eventually abort or commit. Therefore it is up to the pro- the transaction eventually committed, the value of the vari- grammer to use aborts wisely or to prevent inconsistent views able would have been the same. Furthermore, if a variable is a from causing problems, by prechecking invariants at the out- part of an invariant, the transaction will not expose it, until all set of a transaction, or maintaining invariants also within other variables involved in the invariant reach a fixed point a transaction (in a similar way as with monitor invariants). within that transaction. So, if the transaction is eventually Alternatively, a mechanism can be built into the TM that pre- forced to abort rather than committing, the value of any vari- vents specific transactions at risk from reading variables that able prereleased would be the same regardless of whether the were prereleased, while other transactions are allowed to do transaction committed or aborted. Therefore, we can consider so. However, if these workarounds are not satisfactory, we the inconsistent state to be safe. In other words, if the variable present a stronger variant of last-use opacity in Sect. 6 that caused an error to occur, the error would be caused regardless deals specifically with this model and eliminates its incon- of whether the transaction finally aborts or commits. Thus, sistent views. we can say that with this set of assumptions, the programmer is guaranteed that none of the inconsistent views will cause 5.5.3 Restricted abort model unexpected behavior, even if cascading aborts are possible. Note that the use of this model is not uncommon (see eg. We present a third alternative to aborts in transactions: a [3,4,15]), and there are transactional systems that restrict the compromise between only forced aborts and programmer- API even further by precluding aborts completely [1,30]. initiated aborts. This option assumes that the tryA operation is not available to the programmer, so it cannot be used to 5.5.2 Arbitrary abort model implement business logic. However, we allow the TM system to somehow inject tryA operations in the code in response Alternatively, let us assume that transactions can arbitrarily to external stimuli, such as crashes or exceptions and use abort (in addition to forced aborts as described above) by aborts as a fault tolerance mechanism. However, since the executing the operation tryA as a result of some instruction programmer cannot use the operation, the programs must be in the program. In that case it is possible to imagine programs coded as in the commit-only model, and therefore the same that use the abort instruction to cancel a transaction due to guarantees are given as in the commit-only model. the “business logic” of the program. Therefore a program- mer explicitly specifies that the value of a variable is different 5.6 Strength depending on whether the transaction finally commits or not. An example of such a program is given in Fig. 24 (subpro- We compare the relative strength of last-use opacity with gram P ). Here, the programmer enforced an invariant that other properties from Sect. 4 and present the result of the the value of x should never be less than zero. If the invari- comparison in Fig. 26. We provide the proofs for each com- ant is not fulfilled, the transaction aborts. However, writing a parison in the appendix. value to x that breaks the invariant is the closing write opera- tion execution for this program, so it is possible that another transaction reads the value of x before the transaction aborts. 5.7 Performance If the transaction that reads x is like the one in Fig. 24 (sub- program P ), where x is used to index an array via pointer In general, parallelizing transactions is an important com- arithmetic, a memory error is possible. Nevertheless, the his- ponent of TM performance and other research has shown tory from Fig. 25 that corresponds to a problematic execution that doing so by allowing reading from live transactions can 123 292 K. Siek, P. T. Wojciechowski Fig. 26 Strength of last-use opacity be very beneficial [1,35,37]. More specifically, existing last- operations. Thus, strong last-use opacity defines its own vari- use–opaque implementations of pessimistic and distributed ant of a closing write to be any write operation execution TM systems show that prerelease yields a performance bene- that is not followed by another write on the variable, nor any fit in terms of throughput in experimental scenarios with high voluntary abort. In this way, transactions that can start a cas- contention [26,40,41]. In those cases transactions that prere- cading abort are prevented from prereleasing. This means that lease variables can execute partially in parallel with other inconsistent views are excluded, while prereleasing transac- transactions that depend on the same variables. In contrast, tions are prevented from aborting. counterpart opaque implementations are forced to essentially Below we define the concept of a strongly closing write serialize such transactions. The effect is more pronounced to some variable by a particular transaction: we first define a in write-heavy workloads, since parallelizing writer trans- strongly closing write operation invocation, and then extend actions with one another involves some form of prerelease. the definition to complete operation executions. The performance bump is also more apparent with longer Definition 25 (Strongly Closing Write Invocation)Given transactions (both in terms of local operations and shared a program P, a set of invariants I, a set of processes Π variable accesses), because the difference between reading a executing P, and a history H s.t. H | E (P,Π),aninvo- value at the time it is written vs waiting until the live trans- cation inv (w(y)v) on some variable y by transaction T in action commits is greater. However, we also see that in low H is the strongly closing write invocation on some vari- contention, last-use–opaque implementations do less well, able x by transaction T in H,if y ∈ I and for any history since the locking and prerelease mechanisms are more costly P,Π H ∈ H for which H and H have a common prefix than speculative execution. Practical applications could ben- P ending with inv (w(y)v) i.e., P = P ·[inv (w(y)v)], i i efit from adaptively managing prerelease and the associated H = P · R, and H = P · R , there is no operation mechanisms by monitoring contention and enabling them invocation inv s.t. inv (w(y)v) precedes inv in H |T and only when contention is sufficiently high. either (a) inv = inv (w(z)u) for any variable z ∈ I ,or(b) i i inv = inv (tryA). The remainder of the definitions of strong last-use opac- 6 Strong last-use opacity ity are formed by analogy to their counterparts in last-use opacity. Note that these definitions do not preclude some Even though last-use opacity prevents inconsistent views in other operation than tryA returning A after a strongly clos- the commit-only and restricted abort models, it does not pre- ing write. vent inconsistent views in the arbitrary aborts model. Hence, The definition of a strongly closing write operation execu- we present a stronger variant of last-use opacity. Strong last- tion is analogous to that of closing write operation execution use opacity extends the definition of a closing write operation Definition 21. The strongly closing write is used instead of to take tryA operations into account, as if it were an operation the closing write to define a transaction strongly decided on that modifies a given variable. x in analogy to Definition 22. Then, that definition is used ˆ ˆ ˘ ˆ ˆ to define T , H |T , and H |T by analogy to T , H |T and j j j 6.1 Intuition and definition H |T . Next, those definitions are used to define SLVis by analogy to LVis. Finally, we say a transaction T is strongly Strong last-use opacity is very similar to last-use opacity: it last-use legal in some sequential history S if SLVis(S, T ) requires restraint and it prevents transactions from reading is legal. This allows us to define strong last-use opacity as from other live transactions, unless the transaction is guar- follows. anteed not to further modify the variable in question and all required invariants are preserved. The difference between Definition 26 (Final-state Strong Last-use Opacity) A finite last-use opacity and strong last-use opacity is that the latter history H is final-state strongly last-use opaque if, and only also considers aborts as operations that modify the variable, if, there exists a sequential history S equivalent to Compl(H ) whereas last-use opacity only considers writes to be such s.t., 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 293 Table 2 Histories satisfied by different variants of last-use opacity Figures Description Last-use opaque Strongly last-use opaque Figure 11 Prerelease Figure 12 Prerelease to aborting transaction Figure 13 Prerelease with two aborting transactions × Figure 14 Prerelease before closing write ×× Figure 15 Prerelease with two aborting transactions before closing write ×× Figure 16 Prerelease to a prematurely aborting transaction Figure 17 Commit order not respected ×× Figure 18 Reversed commit order in writer transactions Figure 19 Freedom to read or ignore an aborted transaction × Figure 20 Prerelease with overwriting ×× Figure 21 Dependency cycle ×× (a) S preserves the real-time order of H, effect, the reading transactions are not strongly legal, which (b) every transaction in S that is committed in S is legal in causes the histories to fail to satisfy strong last-use opacity. S, (c) every transaction in S that is not committed in S is 6.3 Guarantees strongly last-use legal in S, (d) H is restrained. Strong last-use opacity gives most of the same guarantees as last-use opacity: serializability, real-time order, recover- Definition 27 (Strong Last-use Opacity) A history H is ability, precluding overwriting, and aborting prerelease (in strongly last-use opaque if, and only if, every finite prefix the case of forced aborts). We forgo formal definitions and of H is final-state strongly last-use opaque. proofs of these, since they are analogous to those in Sect. 5.3. Theorem 2 Strong last-use opacity is a safety property. 6.4 Strength Proof By Definition 27, strong last-use opacity is trivially prefix-closed. We compare the relative strength of strong last-use opacity Given H that is an infinite limit of any sequence of finite with last-use opacity and other properties from Sect. 4 and histories H , H ,...,s.t every H in the sequence is strongly present the result of the comparison in Fig. 27. The proofs 0 1 h last-use opaque and every H is a prefix of H , since each are analogous to those for last-use opacity. We also discuss h h+1 prefix H of H is strongly last-use opaque, then, by exten- how strong last-use opacity compares with last-use opacity h L sion, every prefix of H is also final-state strongly last-use in various abort models below. opaque, so, by Definition 27, H is strongly last-use opaque. In the commit-only model, the strong last-use opacity Hence, strong last-use opacity is limit-closed. property is equivalent to last-use opacity. This is trivial, since Since strong last-use opacity is both prefix-closed and if there are no tryA operations in any history, then the defi- limit-closed, then, by Definition 1, it is a safety property. nition of a strong closing write invocation is identical to the definition of a closing write invocation. In the arbitrary abort model, strong last-use opacity prop- 6.2 Examples erty is strictly stronger than last-use opacity, because the definition of strong closing writes excludes histories that last- In Table 2 we show whether the examples in Figs. 11, 12, 13, use opacity allows, including those with cascading aborts 14, 15, 16, 17, 18, 19, 20 and 21 satisfy strong last-use opacity initiated by a voluntary abort. alongside last-use opacity. Note that the properties allow and In the restricted abort model, strong last-use opacity prop- exclude histories in the same way except for two: Figs. 13 erty is also strictly stronger than last-use opacity, but it is too and 19. In those histories an aborting transaction prereleases strong to be applicable to systems with prerelease. In the first a variable, which means that each such transaction’s last write place, even though the histories that are excluded by strong was not, in fact, strongly closing, even though it was closing. last-use opacity contain inconsistent views, these are harm- This means that the write cannot be included in SLVis of the less, because as we argue in Sect. 5.5, transactions always other transaction that read from the aborting transaction. In release variables with “final” values. Since the tryA opera- 123 294 K. Siek, P. T. Wojciechowski Fig. 27 Strength of strong last-use opacity Table 3 Summary of prerelease support in new properties Property Application Definition 3 Definition 4 Definition 5 ⊆ Serializable Last-use opacity TM × Strong last-use opacity TM × tion is not available to the programmer, these final values the last column informs whether each property is at least as cannot be reverted by a programmer-initiated abort, so if the strong as serializability. programmer or TM algorithm sets up a closing write to a vari- The table shows that both of the introduced properties able in a transaction, the value that was written was expected allow prerelease without a requirement for transactions that to both remain unchanged and be committed. Hence, it is prerelease not to abort. Nevertheless the properties are strong acceptable for these values to be read by other transactions, enough to prevent most inconsistent views and make others even before the original transaction commits. inconsequential. Specifically, neither property admits incon- Finally, in both the restricted and the arbitrary abort mod- sistent views in the commit-only model and the compromise els (but especially the former), we assume that a TM system restricted abort model. Last-use opacity allows a narrow class can inject a tryA operation into the transactional code to of inconsistent views in the arbitrary abort model, which can respond to some outside stimuli, such as crashes. Such events be mitigated by the programmer. On the other hand, the strong are unpredictable, so it may be possible for any transac- last-use opacity variant eliminates inconsistent views in all tion to abort at any time. Hence, it is necessary to assume models, although does so for the price of preventing pre- that a tryA operation can be produced as the next operation release in transactions that invoke the tryA operation. We invocation in any transaction at any time. In effect, as the consider strong last-use opacity and last-use opacity to be definition of strong last-use opacity does not allow a transac- practical safety properties for TM systems that employ pre- tion to prerelease a variable if a tryA is possible in the future, release. strong last-use opacity may prevent prerelease altogether in the restricted abort model. In summary, strong last-use opacity is a useful variant of 7 Related work last-use opacity to exclude inconsistent views in the arbi- trary abort model (if workarounds suggested in Sect. 5.5 are Ever since opacity [16,17] was introduced, it seems, there insufficient solutions). However strong last-use opacity may were attempts to weaken its stringent requirements, while be too strict for TMs operating in the restricted and arbitrary retaining some guarantees over what serializability [7,33] abort models, where it may prevents prerelease altogether, provides. We explore the most pertinent examples in Sect. 4: depending on whether the injection of a tryA invocation into TMS1, TMS2 [13], elastic opacity [15], live opacity [14], a transaction’s code can be predicted or not. Certainly, in sys- and VWC [23], as well as some apposite consistency cri- tems where aborts are used as a response to partial failures, teria: recoverability [18], cascadelessness [8], strictness [8], strong last-use opacity prevents prerelease altogether. commit ordering [44] and rigorousness [10]. Other attempts were more specialized and include virtual time opacity [23], where the real-time order condition is relaxed. 6.5 Summary Similarly, the opacity family of properties [25] relax the time ordering requirements of opacity to provide properties In Table 3 we present a summary of the properties discussed applicable to deferred update replication. Another example in this section by analogy to the summary in Table 1. The table is view transactions [2], where it is only required that a trans- informs that a particular property is a TM safety property action commits on any snapshot, that can be different than and whether it satisfies the definitions for prerelease support, the one the transaction viewed initially, provided that operat- overwriting support, and aborting prerelease support. Finally, ing on either snapshot produced externally indistinguishable 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 295 results. While these properties have specific applications, means that DATM allows overwriting, as well as cascading none weaken the consistency to allow variable access before aborts. It also means that it does not satisfy last-use opacity. commit. In [37], the authors proposed algorithms for processing Although algorithms and systems are not the focus of this transactions in a predefined order. The work associates each paper, some systems research that explores relaxed consis- transaction with a unique age attribute that is known apri- tency should be noted. Dynamic STM [21] can be credited ori and reprised for retries, and which is then used to direct with introducing the concept of early release in the TM con- concurrency control and ensure that transactions commit text. Dynamic STM allows transactions that only perform in the order of age (a property called Age-based Commit read operations on particular variables to (manually) release Order). The paper introduces an algorithm that allows read- them for use by other transactions. However, it left the assur- ing from live transactions, Ordered Undo Log (OUL), and ance of safety to the programmer, and, as the authors state, its variant with co-operative writers, OUL-stealing. These even linearizability cannot be guaranteed by the system. The algorithms outperform other implementations in most bench- authors of [42] expanded on the work above and evaluated the marks, showing a clean performance benefit to reading from concept of early release with respect to read-only variables live transactions. The paper shows that OUL and OUL- on several concurrent data structures. The results showed that stealing are strictly serializable, but since they both allow early release does not provide a significant advantage in most overwriting, neither is last-use–opaque. cases, although there are scenarios where it would be advan- Finally, SVA is a distributed TM system introduced in [41] tageous if it were automated. Prerelease expands this idea (building on an earlier non-distributed rollback-free variant further by allowing writers to expose written values before from [46–48]). The main aspect of SVA is the ability to prere- attempting to commit. lease variables. The prerelease mechanism in SVA is based on In [1], the authors introduce a pessimistic lock elision apriori knowledge about the maximum number of accesses algorithm (improving on pessimistic algorithms introduced that a transaction can perform on particular variables. A trans- in [30,34]), where read/write transactions are serialized, action that knows it performed exactly as many operations while read-only transactions are wait-free. Write transactions on some variable as the upper bound allows may then release write values directly into memory, but maintain a bounded that variable. SVA does not require the upper bounds to be log of overwritten values. The read transactions prevent con- precise, and can handle situations when they are either too flicting with writers by accessing older but consistent values great (some variables are not prereleased) or too low (transac- from the log, if a variable was overwritten. In effect, the algo- tions are aborted). The resulting parallelization of transaction rithm allows multiple readers to operate in parallel showing a executions leads to improved performance [26,41]. The algo- performance improvement. The parallelization is done with- rithm was further extended to produce OptSVA [40], that uses out prerelease, although at the cost of serializing writers, buffering to expedite the execution of read-only transactions logging values, and reading out of date values. and defer writes in write-only ones and whose implemen- Twilight STM [9] relaxes isolation to allow transactions to tation outperforms its predecessor. Both OptSVA and SVA read variables that are used by other transactions, and allow satisfy last-use opacity. them to re-read their values as they change in order to main- tain the correctness of the computation. If inconsistencies arise, a reconciliation is attempted on commit, and aborts 8 Conclusions are induced if this is impossible. Since it allows operating on variables that were prereleased, but potentially before a This paper explored the space of TM safety properties in closing write, Twilight STM will not satisfy the consistency terms of whether or not, and to what extent, they allow a requirements of last-use opacity, but it is likely to guarantee transaction to prerelease a variable, or, in other words, for a serializability and recoverability. transaction to read a value written by a live transaction. We DATM [35] is yet another noteworthy system with a prere- showed that existing properties are either strong, but prevent lease mechanism. DATM is an optimistic multicore-oriented prerelease altogether (opacity, TMS1 and TMS2), or pose TM based on TL2 [12], augmented with prerelease support. impractical restrictions on the ability of transactions to abort It allows a transaction T to write to a variable that was (VWC and live opacity). The remainder of the properties accessed by some uncommitted transaction T , as long as are not strong enough for TM applications (serializability T commits before T . DATM also allows transaction T to and recoverability) since they allow a large range of incon- j i i read a speculative value, one written by T and accessed by sistent views, including overwriting. Hence, we presented a T before T commits. DATM detects if T overwrites the new TM safety property called last-use opacity that strikes i j j data or aborts, in which case T is forced to restart. DATM a reasonable compromise at the price of explicitly including allows all schedules allowed by conflict-serializability. This reasoning about transactional code and invariants in safety considerations. It allows prerelease without a requirement 123 296 K. Siek, P. T. Wojciechowski for transactions that prerelease variables not to abort, but one Proof From Definition 11, for any final-state opaque history that is nevertheless strong enough to prevent most inconsis- H, there is a sequential history S ≡ Compl(H ) s.t. S pre- tent views and make others inconsequential. The resulting serves the real time order of H and every transaction T in S property may be a useful practical criterion for reasoning is legal in S. Thus, for every transaction T in SVis(S, T ) is i i about TMs with prerelease support. legal. Let T , T be any two transactions in H.If T depends i j i We discussed the histories that are allowed by last-use on T then there is a non-local write in T writing some value j j opacity and examined the guarantees the property gives to v to some variable x that some other transaction T (possibly the programmer. Last-use opacity always allows for potential k = i) reads. Since T is legal, then S|T ∈ Vis(S, T ), which k j k inconsistent views to occur due to cascading aborts. However, implies that T is not aborted. Then it is true that either T j i no other inconsistent views are allowed. The inconsistent depends on T or that T aborts, but not both. Therefore, H j j views that can occur can be made harmless by taking away is restrained. the programmer’s ability to execute arbitrary aborts by either Lemma 30 Every final-state opaque history is final-state removing that operation completely or by removing it from last-use–opaque. the programmer’s toolkit, but allowing it to be used by the TM system, e.g. for fault tolerance. Allowing the program- Proof From Definition 11, for any final-state opaque history mers to abort a transaction at will means that they will need H, there is a sequential history S ≡ Compl(H ) s.t. S pre- to eliminate dangerous situations (possible division by zero, serves the real time order of H and every transaction T in invalid memory accesses, etc.) on a case-by-case basis. Nev- S is legal in S. Thus, for every transaction T in SVis(S, T ) i i ertheless, we predict that inconsistent views of this sort will is legal. From the definition of completion, any T is either be relatively rare in practical TM applications, and typically committed or aborted in Compl(H ) and therefore likewise result from using the abort operation to program business completed or aborted in S.If T is committed in S, then it logic. Alternatively, a variant of last-use opacity called strong is legal in S,so Vis(S, T ) is legal, and therefore T is last- i i last-use opacity can be used instead, which eliminates the use legal in S.If T is aborted in S, then it is legal in S,so inconsistent views by preventing prerelease in transactions Vis(S, T ) is legal, and therefore, from Lemma 28, LVis(S, T ) i i where a programmatic abort is possible. is also legal, so T is last-use legal in S. Given that all trans- actions in S are last-use legal in S, and, from Lemma 29, H is restrained, then, from Definition 23, H is final-state last-use Appendix A: Property strength opaque. A.1 Last-use opacity Lemma 31 Every opaque history H is last-use–opaque. Below we compare last-use opacity to other properties and Proof If H is opaque, then, from Definition 12, any prefix consistency conditions to determine their relative strength. P of H is final-state opaque. Since any prefix P of H is final-state opaque, then, from Lemma 30,any P is also final- state last-use opaque. Then, by Definition 24 H is last-use A.1.1 Last-use opacity versus opacity opaque. Opacity is (strictly) stronger than last-use opacity. A.1.2 Last-use opacity versus serializability Lemma 28 For any history S and transaction T ∈ S, if Vis(S, T ) is legal, then LVis(S, T ) is legal. i i Last-use opacity is (strictly) stronger than serializability as shown in Lemma 23. Proof By definition of Vis(S, T ), if operation op ∈ Vis(S, T ), i i then op ∈ Vis(S, T ) only if op ∈ H |T and either i = j or i j A.1.3 Last-use opacity versus virtual world consistency T ≺ T and T is committed. By definition of LVis(S, T ), j S i j i given transactions T , T and operation op ∈ S|T ,if i = j i j j VWC is incomparable to last-use opacity. or T ≺ T and T is committed, then S|T ⊆ LVis(S, T ). j S i j j i Therefore LVis(S, T ) ≡ Vis(S, T ). Since both Vis(S, T ) i i i Lemma 32 There exists a last-use–opaque history H that is and LVis(S, T ) preserve the order of operations in S, then i not virtual world consistent. both LVis(S, T ) and Vis(S, T ) are the same. Hence, if i i Proof Since last-use opacity supports aborting prerelease Vis(S, T ) is legal, then LVis(S, T ) is legal. i i (Lemma 27), then by Definition 3 and by Definition 5 there Lemma 29 Every final-state opaque history is restrained. exists some last-use–opaque history where some transac- tion reads from a live transaction which subsequently aborts. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 297 Fig. 28 VWC history example [24] Fig. 29 TMS1 history example [13] Since, by Lemma 16, VWC does not support aborting releas- Lemma 35 There exists a TMS1 history H that is not last- ing transactions, then, by the same definitions, such a history use–opaque. is not VWC. Hence a history with a transaction prereleasing Proof Let history H be the history presented in Fig. 29.In may be last-use–opaque but not VWC. [13] (Fig. 6 therein) the authors show that the history satisfies Lemma 33 There exists a virtual world consistent history H TMS1. The same history is not last-use opaque. Note that if that is not last-use–opaque. Vis(S, T ) is to be legal, in any S equivalent to H, T ≺ i i S T , because T reads 0 from x and T writes 2 to x (and j i j Proof Let history H be the history presented in Fig. 28. commits). In addition, T ≺ T , because T reads 2 from x j S l l In [24] (Fig. 2 therein) the authors declare that the history and T ≺ T , because T reads z from T . Then, by extension k S l l k satisfies VWC. The same history is not last-use opaque, T ≺ T ≺ T . However, note that in any S it must be that i S j S l because for any witness history S, LVis(S, T ) must contain T ≺ T , because T reads 0 for y, which is a contradiction. l S i l H |T · H |T · H |T . Since r (x)1 is preceded in LVis(S, T ) by j k l l Thus, H is not last-use opaque. w(x)2, then LVis(S, T ) is not legal. Thus, H is not final-state last-use opaque, and so H is not last-use opaque. TMS2 is (strictly) stronger than last-use opacity. A.1.4 Last-use opacity versus transactional memory Proposition 1 All TMS2 histories are last-use–opaque. specification Proof The authors of [13] believe (but do not demonstrate) TMS1 is incomparable to last-use opacity. that every execution allowed by TMS2 also satisfies opacity (modulo cosmetic interface differences). If this is the case, Lemma 34 There exists a last-use–opaque history H that is then, since all opaque histories are last-use–opaque (Lemma not TMS1. 31), then it is true that all TMS2 histories satisfy last-use- Proof Since last-use opacity supports aborting prerelease opacity. Thus, we believe the proposition is true, pending a (Lemma 27), then from Definition 5 it necessarily follows demonstration that all TMS2 histories satisfy opacity. that it supports prerelease. In that case, if follows from Defi- nition 3 that there exists some last-use–opaque history where A.1.5 Last-use opacity versus cascadelessness some transaction reads from a live transaction which subse- quently aborts. Since, by Lemma 13 TMS1, does not support Cascadelessness is incomparable to last-use opacity. prerelease, then, by the same definitions, histories containing prerelease are not TMS1. Hence a history with a transaction Lemma 36 There exists a last-use–opaque history H that is prereleasing may be last-use–opaque but not TMS1. not cascadeless. 123 298 K. Siek, P. T. Wojciechowski Fig. 30 Cascadeless history that does not satisfy last-use opacity Fig. 31 Last-use–opaque history that does not satisfy elastic opacity Proof Let H be the history in Fig. 11. Since T reads from Proof Let history H be the history presented in Fig. 31.It T in H and r (x) → 1 ≺ tryC → C the history is should be straightforward to see that H is last-use–opaque for i j H i not cascadeless, since it contradicts Definition 9.Let C = an equivalent sequential history S = H |T · H |T . Operations i j Compl(H ) s.t. H = C, and let S be a sequential history s.t. on z are always justified in any sequential equivalent history ˆ ˆ ˆ S = C |T · C |T . Then Vis(S , T ) = S |T =[w (x)1 → since they are all within T and their effects are not visible H i j H i H i i i ˆ ˆ ˆ in T . The read operation on y is expected to read 0 since it ok ] and LVis(S , T ) = S |T · S |T =[w (x)1 → j i H j H i H j i is not preceded in S by any write, and it does read 0. Thus ˆ ˆ ok , r (x) → 1]. Trivially, Vis(S , T ) and LVis(S , T ) are i j H i H j operations on y and z will not break legality of either T or both legal, so T is committed and legal, and T is last-use i j T . With that in mind, the history can be shown to be last-use legal. Thus H is final-state last-use opaque. By analogy, all opaque by analogy to Lemma 36. prefixes of H are also final-state last-use opaque, so H is On the other hand, let T be an elastic transaction. The last-use opaque. i only possible well-formed cut of H |T is C ={[r(z) → i i Lemma 37 There exists a cascadeless history H that is not 0, w(x )1 → ok, r(y) → 0, w(y)1 → ok]}. (In particular, last-use–opaque. the following cut is not well-formed, since w(x )1 → ok and w(y)0 → ok are in two different subhistories of the cut: Proof The history in Fig. 30 is shown to be cascadeless C ={[r(z) → 0, w(x )1 → ok], [r(y) → 0, w(y)1 → ok]}). (ACA) in [5]. However, note, that Compl(H ) = H, and i Let f (H ) be a cutting function that applies cut C. Then, given any sequential S ≡ Compl(H ) T must follow both T k i since the cut contains only one subhistory, it should be and T in S because T reads from both transactions. Since j k straightforward to see that f (H ) = H. Then, we note that T ≺ T and T ≺ T , then T must precede both other i H j i H k i H contains an operation in H |T that reads the value of x transactions in S. from H |T and T is live. That means that in the prefix P of i i Hence, S = H |T · H |T · H |T ,so Vis(S, T ) = S and i j k k H s.t. H = P ·[tryC → C , tryC → C ] both transactions i j therefore Vis(S, T ) is illegal because r (x) → 1 is preceded i j k k will be aborted in any completion of P, so for any sequential in Vis(S, T )|x by w (x)2 →ok . k j j equivalent history SVis(S, T ) will not contain S|T , since i j T is aborted in any S. Therefore Vis(S, T ) will not justify j i A.1.6 Last-use opacity versus elastic opacity reading 1 from x and will not be legal, causing P not to be final state opaque (Definition 11), which in turn means that Last-use Opacity and elastic opacity are incomparable. H is not opaque (Definition 12). Lemma 38 There exists an elastic opaque history H that is not last-use–opaque. A.1.7 Last-use opacity versus recoverability Proof Since elastic opaque histories may not be serializ- able [15], and since, as all last-use–opaque histories trivially Last-use opacity is (strictly) stronger than recoverability. require serializability then some elastic opaque histories are not last-use–opaque. Lemma 40 Every last-use–opaque history H is recoverable. Lemma 39 There exists a last-use–opaque history H that is not elastic opaque. Proof From Lemma 25. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 299 A.1.8 Last-use opacity versus strictness H reads from a live transaction (in any prefix of H). There- fore, since S is legal, any read operation op = r (x) →v in Strictness and last-use opacity are also incomparable. H that is preceded by w (x)v → u in H, T is committed in j j S and is included in S in full. Lemma 41 There exists a last-use–opaque history H that is Let S be a sequential history constructed by replacing the not strict. operations removed to create S where if T ∈ H and T ∈ / S i i then T is aborted in S . S preserves the real time order of H Proof Since any strict history is also ACA [5], and since and S ≡ H. Note that, since S is legal, if some write op is Lemma 36 shows that not all last-use–opaque histories are in S and not in S , then there is no non-local read operation ACA, then not all last-use–opaque histories are strict. r w op reading the value written by op . Hence any operation reading the value written by op is local, and since all local Lemma 42 There exists a strict history H that is not last- reads in transactions that are replaced in S read legal values use–opaque. (by Definition 17), then all reads reading from any op read legal values in S . Since S is legal, then all reads reading Proof The history in Fig. 30 is shown to be strict in [5]. from transactions that are in S read legal values in S . Since However, as we show in Lemma 37, this history is not S ≡ H, then these read and write operations also read legal last-use–opaque. values in S . Because of this, and since no transaction reads from another live transaction, Vis(S , T ) will be legal for A.1.9 Last-use opacity versus rigorousness any transaction in S . In addition, LVis(S , T ) will be legal for any aborted transaction in S . Therefore, and given that Rigorousness is (strictly) stronger than last-use opacity. any live opaque H is restrained (Lemma 44), any live opaque Lemma 43 Every rigorous history H is last-use–opaque. H will be final state last-use opaque. Since any prefix of H is also live opaque, then any prefix will also be final-state Proof Since [5] demonstrates that rigorous histories are last-use opaque, hence H is last-use opaque. opaque, and since we show in Lemma 31 that opaque histo- ries are also last-use–opaque, then all rigorous histories are A.1.11 Last-use opacity versus markability last-use–opaque. Lemma 46 Every markable history H is last-use–opaque. A.1.10 Last-use opacity versus live opacity Proof Trivially from Lemma 31. Live opacity is (strictly) stronger than last-use opacity. A.1.12 Last-use opacity versus commitment order preservation Lemma 44 Every live opaque history is restrained. Proof Let H be a live opaque history. Let S be any sequential CO and last-use opacity are incomparable. history that justifies the serializability of H, and let S be any Lemma 47 There exists a last-use–opaque history H that is sequential extension of S in accordance to Definition 17.Let not CO. T , T be any two transactions in H.If T depends on T then i j i j there is a non-local write in T writing some value v to some Proof Let H be the history in Fig. 18. Since both H |T variable x that some other transaction T (possibly k = i) and H |T each contain a single write operation on x, then gr reads. Since S is legal, and since T does not contain write j ˆ ˆ for any equivalent sequential history S ,all of Vis(S , T ), H H i operations, then it must be true that T ∈ S (as opposed to ˆ ˆ ˆ Vis(S , T ), LVis(S , T ), and LVis(S , T ) are always H j H i H j gr T ∈ S). That means that T does not abort. Then it is true legal. Hence, H is final-state last-use opaque. Since the that either T depends on T or that T aborts, but not both. i j j conclusion follows for any prefix of H, then any prefix is Therefore, H is restrained. final-state last-use opaque, and H is last-use opaque. How- ever, since T and T conflict, and since T executes its write i j i Lemma 45 Every live opaque history H is last-use–opaque. on x before T ,but T commits before T , then H is not CO. j j i Proof Since H is live opaque there exists a sequential his- tory S that justifies serializability of H and an extension S Lemma 48 There exists a CO history H that is not last-use of S where if transaction T is not in S then it is replaced opaque. gr in S by T containing only non-local reads. S is legal and preserves the real-time order of H (accounting for replaced Proof We show in Lemma 5 that CO supports overwriting, so transactions). In addition, from Lemma 19, no transaction in by Definition 4, there exists some H that contains overwriting 123 300 K. Siek, P. T. Wojciechowski and satisfies CO. We show in Lemma 26 that last-use opacity References precludes overwriting, so such H is not last-use opaque. 1. Afek, Y., Matveev, A., Shavit, N.: Pessimistic software lock-elision. In: Proceedings of DISC’12: The 26th International Symposium on Distributed Computing (2012) A.2 Strong last-use opacity 2. Afek, Y., Morrison, A., Tzafrir, M.: Brief announcement: view transactions: transactional model with relaxed consistency checks. Strong last-use opacity is strictly stronger than last-use opac- In: Proceedings of PODC’10: The 29th ACM SIGACT-SIGOPS ity. Symposium on Principles of Distributed Computing (2010) 3. Attiya, H., Gotsman, A., Hans, S., Rinetzky, N.: A programming language perspective on transactional memory consistency. In: Lemma 49 For any history S and transaction T ∈ S, if Proceedings of PODC’13: The 32nd ACM SIGACT-SIGOPS Sym- posium on Principles of Distributed Computing (2013) SLVis(S, T ) is legal, then LVis(S, T ) is legal. i i 4. Attiya, H., Gotsman, A., Hans, S., Rinetzky, N.: Safety of live trans- actions in transactional memory: TMS is necessary and sufficient. In: Proceedings of DISC’14: The 28th International Symposium Proof Given SLVis(S, T ) and LVis(S, T ) and some opera- i i on Distributed Computing (2014) tion op ∈ H |T , then from definitions of SLVis and LVis: 5. Attiya, H., Hans, S.: Transactions are back—but how different they are? In: Proceedings of TRANSACT’14: The 7th ACM SIGPLAN Workshop on Transactional Computing (2014) (a) i = j or both T is committed in S and T ≺ T then j j S i 6. Attiya, H., Hans, S., Kuznetsov, P., Ravi, S.: Safety of deferred op ∈ SLVis(S, T ) and op ∈ LVis(S, T ). update in transactional memory. In: Proceedings of ICDCS’13: The i i 33rd International Conference on Distributed Computing Systems ˆ ˆ (b) if T is not committed in S but T ∈ T ∩ T and j j (2013) T ≺ T , and it is not true that T ≺ T , then either j S i j H i 7. Bernstein, P., Shipman, D., Wong, W.: Formal aspects of serializ- both op ∈ SLVis(S, T ) and op ∈ LVis(S, T ) or both ability in database concurrency control. IEEE Trans. Softw. Eng. i i SE–5(3), 203–216 (1979) op ∈ / SLVis(S, T ) and op ∈ / LVis(S, T ). i i 8. Bernstein, P.A., Hadzilacos, V., Goodman, N.: Concurrency Con- trol and Recovery in Database Systems. Addison-Wesley, Boston (1987) Then op ∈ Vis(S, T ) only if it is true that op ∈ H |T i j 9. Bieniusa, A., Middelkoop, A., Thiemann, P.: Brief announcement: and in addition either i = j or both T ≺ T and T j S i j actions in the twilight—concurrent irrevocable transactions and is committed. By definition of SLVis(S, T ), given transac- inconsistency repair. In: Proceedings of PODC’10: The 29th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Com- tions T , T and operation op ∈ S|T ,if i = j or T ≺ T i j j j S i puting (2010) and T is committed, then S|T ⊆ SLVis(S, T ). Therefore j j i 10. Breitbart, Y., Georgakopoulos, D., Rusinkiewicz, M., Silberschatz, SLVis(S, T ) ≡ Vis(S, T ). Since Vis(S, T ) and SLVis(S, T ) i i i i A.: On rigorous transaction scheduling. IEEE Trans. Softw. Eng. preserve the order of operations in S, then SLVis(S, T ) = 17(9), 954–960 (1991) 11. Dalessandro, L., Scott, M.L.: Sandboxing transactional memory. Vis(S, T ). Hence, if Vis(S, T ) is legal, then SLVis(S, T ) is i i i In: Proceedings of PACT’12: The 21st International Conference legal. on Parallel Architectures and Compilation Techniques (2012) 12. Dice, D., Shalev, O., Shavit, N.: Transactional Locking II. In: Proceedings of DISC’06: The 20th International Symposium on Corollary 18 Any strongly last-use opaque history H is last- Distributed Computing (2006) use–opaque. 13. Doherty, S., Groves, L., Luchangco, V., Moir, M.: Towards for- mally specifying and verifying transactional memory. Form. Asp. Comput. 25(5), 769–799 (2013) The remaining proofs are by analogy to Sect. A. 1. 14. Dziuma, D., Fatourou, P., Kanellou, E.: Consistency for transac- tional memory computing. Bull. EATCS 2(113), 3 (2014) Acknowledgements We would like to thank the anonymous reviewers 15. Felber, P., Gramoli, V., Guerraoui, R.: Elastic transactions. In: for their diligence and insight that led to substantial improvements to Proceedings of DISC’09: The 23rd International Symposium on our work. Distributed Computing (2009) 16. Guerraoui, R., Kapałka, M.: On the correctness of transactional Open Access This article is licensed under a Creative Commons memory. In: Proceedings of PPoPP’08: The 13th ACM SIGPLAN Attribution 4.0 International License, which permits use, sharing, adap- Symposium on Principles and Practice of Parallel Programming tation, distribution and reproduction in any medium or format, as (2008) long as you give appropriate credit to the original author(s) and the 17. Guerraoui, R., Kapałka, M.: Principles of Transactional Memory. source, provide a link to the Creative Commons licence, and indi- Morgan & Claypool, San Rafael (2010) cate if changes were made. The images or other third party material 18. Hadzilacos, V.: A theory of reliability in database systems. J. ACM in this article are included in the article’s Creative Commons licence, 35(1), 121–145 (1988) unless indicated otherwise in a credit line to the material. If material 19. Harris, T., Fraser, K.: Language support for lightweight transac- is not included in the article’s Creative Commons licence and your tions. In: Proceedings of OOPSLA’03: The 18th ACM SIGPLAN intended use is not permitted by statutory regulation or exceeds the Conference on Object-Oriented Programming, Systems, Lan- permitted use, you will need to obtain permission directly from the copy- guages, and Applications (2003) right holder. To view a copy of this licence, visit http://creativecomm ons.org/licenses/by/4.0/. 123 Last-use opacity: a strong safety property for transactional memory with prerelease support 301 20. Harris, T., Marlow, S., Peyton Jones, S., Herlihy, M.: Compos- 36. Ringenburg, M.F., Grossman, D.: AtomCaml: first-class atom- able memory transactions. In: Proceedings of PPoPP’05: The ACM icity via rollback. In: Proceedings of ICFP’05: The 10th ACM SIGPLAN Symposium on Principles and Practice of Parallel Pro- SIGPLAN International Conference on Functional Programming gramming (2005) (2005) 21. Herlihy, M., Luchangco, V., Moir, M., Scherer, I.W.N.: Soft- 37. Saad, M.M., Kishi, M.J., Jing, S., Hans, S., Palmieri, R.: Processing ware transactional memory for dynamic-sized data structures. In: transactions in a predefined order. In: Proceedings of PPoPP’19: Proceedings of PODC’03: The 22nd ACM SIGACT-SIGOPS Sym- The 24th Symposium on Principles and Practice of Parallel Pro- posium on Principles of Distributed Computing (2003) gramming (2019) 22. Herlihy, M., Moss, J.E.B.: Transactional memory: architectural 38. Saha, B., Adl-Tabatabai, A., Hudson, R.L., Minh, C.C., Hertzberg, support for lock-free data structures. In: Proceedings of ISCA’93: B.: McRT-STM: a high performance software transactional mem- The 20th International Symposium on Computer Architecture ory system for a multi-core runtime. In: Proceedings of PPoPP’06: (1993) The ACM SIGPLAN Symposium on Principles and Practice of 23. Imbs, D., de Mendivil, J.R., Raynal, M.: On the consistency con- Parallel Programming (2006) ditions or transactional memories. Tech. Rep. 1917, IRISA (2008) 39. Shavit, N., Touitou, D.: Software transactional memory. In: Pro- 24. Imbs, D., Raynal, M.: Virtual world consistency: a condition for ceedings of PODC’95: The 14th ACM SIGACT-SIGOPS Sympo- STM systems (with a versatile protocol with invisible read opera- sium on Principles of Distributed Computing (1995) tions). Theor. Comput. Sci. 444, 113–127 (2012) 40. Siek, K., Wojciechowski, P.T.: Atomic RMI 2: highly parallel pes- 25. Kobus, T., Kokocinski, ´ M., Wojciechowski, P.T.: Relaxing real- simistic distributed transactional memory. abs/1606.03928 (2016). time order in opacity and linearizability. J. Parallel Distrib. Comput. arXiv:1606.03928 100, 57–70 (2017) 41. Siek, K., Wojciechowski, P.T.: Atomic RMI: a distributed transac- 26. Kobylinski, ´ P., Siek, K., Baranowski, J., Wojciechowski, P.T.: tional memory framework. Int. J. Parallel Program. 44(3), 598–619 Helenos: a realistic benchmark for distributed transactional mem- (2016) ory. J. Softw. Pract. Exp. 48(3), 528–549 (2018) 42. Skare, T., Kozyrakis, C.: Early release: friend or foe? In: Pro- 27. Konczak, ´ J.Z., Wojciechowski, P.T., Guerraoui, R.: Operation-level ceedings of WTW’06: The Workshop on Transactional Memory wait-free transactional memory with support for irrevocable opera- Workloads (2006) tions. IEEE Trans. Parallel Distrib. Syst. 28(12), 3570–3583 (2017) 43. Weihl, W.E.: Local atomicity properties: modular concurrency con- 28. Lamport, L.: Proving the correctness of multiprocess programs. trol for abstract data types. ACM Trans. Program. Lang. Syst. 11(2), IEEE Trans. Softw. Eng. SE–3(2), 125–143 (1977) 249–282 (1989) 29. Lesani, M., Palsberg, J.: Decomposing opacity. In: Proceedings 44. Weikum, G., Vossen, G.: Transactional Information Systems: The- of DISC’14: The 28th International Symposium on Distributed ory, Algorithms, and the Practice of Concurrency Control and Computing (2014) Recovery. Morgan Kaufmann Publishers, Burlington (2002) 30. Matveev, A., Shavit, N.: Towards a fully pessimistic STM model. 45. Welc, A., Saha, B., Adl-Tabatabai, A.R.: Irrevocable transactions In: Proceedings of TRANSACT ’12: The 7th ACM SIGPLAN and their applications. In: Proceedings of SPAA’08: The 20th ACM Workshop on Transactional Computing (2012) Symposium on Parallelism in Algorithms and Architectures (2008) 31. Ni, Y., Welc, A., Adl-Tabatabai, A.R., Bach, M., Berkowits, S., 46. Wojciechowski, P.T.: Isolation-only transactions by typing and ver- Cownie, J., Geva, R., Kozhukow, S., Narayanaswamy, R., Olivier, sioning. In: Proceedings of PPDP’05: The 7th ACM SIGPLAN J., Preis, S., Saha, B., Tal, A., Tian, X.: Design and implementation International Symposium on Principles and Practice of Declara- of transactional constructs for C/C++. In: Proceedings of OOP- tive Programming (2005) SLA’08: The 23rd ACM SIGPLAN Conference on Object-oriented 47. Wojciechowski, P.T.: Language Design for Atomicity, Declara- Programming, Systems Languages and Applications (2008) tive Synchronization, and Dynamic Update in Communicating 32. Olszewski, M., Cutler, J., Steffan, J.G.: JudoSTM: a dynamic Systems. Publishing House of Poznan´ University of Technology, binary-rewriting approach to software transactional memory. In: Poznan (2007) Proceedings of PACT’07: The 16th International Conference on 48. Wojciechowski, P.T., Rütti, O., Schiper, A.: SAMOA: a framework Parallel Architectures and Compilation Techniques (2007) for a synchronisation-augmented microprotocol approach. In: Pro- 33. Papadimitrou, C.H.: The serializability of concurrent database ceedings of IPDPS’04: The 18th IEEE International Parallel and updates. J. ACM 26(4), 631–653 (1979) Distributed Processing Symposium (2004) 34. Perelman, D., Fan, R., Keidar, I.: On maintaining multiple ver- sions in STM. In: Proceedings of PODC’10: The 29th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Com- Publisher’s Note Springer Nature remains neutral with regard to juris- puting (2010) dictional claims in published maps and institutional affiliations. 35. Ramadan, H.E., Roy, I., Herlihy, M., Witchel, E.: Committing con- flicting transactions in an STM. In: Proceedings of PPoPP’09: The 14th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (2009)
Distributed Computing – Springer Journals
Published: Jun 1, 2022
Keywords: Transactional memory; Safety property; Consistency
You can share this free article with as many people as you like with the url below! We hope you enjoy this feature!
Read and print from thousands of top scholarly journals.
Already have an account? Log in
Bookmark this article. You can see your Bookmarks on your DeepDyve Library.
To save an article, log in first, or sign up for a DeepDyve account if you don’t already have one.
Copy and paste the desired citation format or use the link below to download a file formatted for EndNote
Access the full text.
Sign up today, get DeepDyve free for 14 days.
All DeepDyve websites use cookies to improve your online experience. They were placed on your computer when you launched this website. You can change your cookie settings through your browser.