# Adaptive Versioning in Transactional Memory Systems +
## 1 Introduction  
Concurrent processes (threads) need to synchronize to avoid introducing inconsistencies while accessing shared data objects. Traditional synchronization mechanisms such as locks and barriers have well-known limitations and pitfalls, including deadlock, priority inversion, reliance on programmer conventions, and vulnerability to failure or delay. _Transactional memory_ (TM) [1, 2] has emerged as an attractive alternative. Several commercial processors provide direct hardware support for TM, including Intel's Haswell [3] and IBM's Blue Gene/Q [4], zEnterprise EC12 [5], and Power8 [6]. There are proposals for adapting TM to clusters of GPUs [7, 8, 9]. Using TM, program code is split into _transactions_, blocks of code that appear to execute atomically. Transactions are executed _speculatively_: synchronization conflicts or failures may cause an executing transaction to _abort_: its effects are rolled back and the transaction is restarted. In the absence of conflicts or failures, a transaction typically _commits_, causing its effects to become visible. Supporting this speculative execution requires _data version management_ mechanism. Many TM systems have been designed using the transactional concept in persistent memories as well as non-persistent (volatile) memories. Those designed TM systems can be distinguished on how they implement data version management. This distinction is true for TM systems implemented in hardware, called hardware TMs (HTMs) [10; 11; 12; 13], as well as implemented in software, called software TMs (STMs) [14; 15; 16]. In this paper, we present a technique that improves on the existing data version management mechanisms used in both persistent and non-persistent TM systems. Essentially, a _versioning_ mechanism handles _data versions_, i.e., the simultaneous storage of both _new_ data (to be visible if transaction commits) and _old_ data (retained if transaction aborts). At most one of these values can be stored \"in place\" (the original memory location), while the other value must be stored \"on the side\" (e.g., in cache or persistent/non-persistent main memory). On a store, a TM system can either use _eager_ versioning and put the new value in place or use _lazy_ versioning to (temporarily) leave the old value in place. Figures 1 and 2 depict how a transaction \(T_{x}\) is executed using eager and lazy versioning in persistent and non-persistent (volatile) TM systems, respectively. Due to the working principle, in both the systems, lazy versioning makes aborts fast but penalizes commits, whereas eager versioning makes commits fast but penalizes aborts. Although both eager and lazy versionings are studied heavily in the literature (details in Section 2) for both persistent [17; 18; 19; 20] and non-persistent TM systems [10; 11; 12; 13; 14; 16; 21], whether to use eager or lazy versioning is still in hot debate for both the systems. In fact, there is no study in persistent/non-persistent TM systems that elaborates the performance gap between eager and lazy versioning with comprehensive practical evaluations, with one notable exception [22] which elaborates on the performance gap partially only for persistent TM systems. The conclusion from [22] is that lazy versioning is appropriate for write-dominated workloads and high contention scenarios whereas eager versioning is appropriate for read-dominated workloads and low contention scenarios. However, to improve performance using lazy or eager versioning, a priori knowledge on the workload as well as the conten  
Figure 1: An illustration of how a transaction \(T_{x}\) is executed in persistent memory using (**a**) eager versioning and (**b**) lazy versioning. Figure (**a**) depicts two kinds of operations in eager versioning. The first operation is to copy the data from original memory locations to a log area (called _undo_ log) in the persistent main memory and the second is to copy the data back from the log area to the original memory locations, in case \(T_{x}\) aborts.