On the Cost of Concurrency in Hybrid Transactional Memory

TL;DR

This paper investigates the inherent costs of concurrency in hybrid transactional memory systems, revealing fundamental limitations and proposing algorithms that balance progressiveness and hardware overhead.

Contribution

It proves that software transactions in progressive hybrid TMs cannot avoid incremental validation and introduces optimal algorithms balancing progressiveness and hardware instrumentation.

Findings

Concurrency cost exists in practice, impacting performance.

Progressiveness for many transactions requires careful hardware design.

Non-speculative hardware accesses do not simplify HyTM efficiency.

Abstract

State-of-the-art \emph{software transactional memory (STM)} implementations achieve good performance by carefully avoiding the overhead of \emph{incremental validation} (i.e., re-reading previously read data items to avoid inconsistency) while still providing \emph{progressiveness} (allowing transactional aborts only due to \emph{data conflicts}). Hardware transactional memory (HTM) implementations promise even better performance, but offer no progress guarantees. Thus, they must be combined with STMs, leading to \emph{hybrid} TMs (HyTMs) in which hardware transactions must be \emph{instrumented} (i.e., access metadata) to detect contention with software transactions. We show that, unlike in progressive STMs, software transactions in progressive HyTMs cannot avoid incremental validation. In fact, this result holds even if hardware transactions can \emph{read} metadata \emph{non-speculatively}. We then present \emph{opaque} HyTM algorithms providing \emph{progressiveness for a subset of transactions} that are optimal in terms of hardware instrumentation. We explore the concurrency vs. hardware instrumentation vs. software validation trade-offs for these algorithms. Our experiments with Intel and IBM POWER8 HTMs seem to suggest that (i) the \emph{cost of concurrency} also exists in practice, (ii) it is important to implement HyTMs that provide progressiveness for a maximal set of transactions without incurring high hardware instrumentation overhead or using global contending bottlenecks and (iii) there is no easy way to derive more efficient HyTMs by taking advantage of non-speculative accesses within hardware.

Full text

We show that, unlike in progressive STMs, software transactions in progressive HyTMs cannot avoid incremental validation. In fact, this result holds even if hardware transactions can read metadata non-speculatively. We then present opaque HyTM algorithms providing progressiveness for a subset of transactions that are optimal in terms of hardware instrumentation. We explore the concurrency vs. hardware instrumentation vs. software validation trade-offs for these algorithms. Our experiments with Intel and IBM POWER8 HTMs seem to suggest that (i) the cost of concurrency also exists in practice, (ii) it is important to implement HyTMs that provide progressiveness for a maximal set of transactions without incurring high hardware instrumentation overhead or using global contending bottlenecks and (iii) there is no easy way to derive more efficient HyTMs by taking advantage of non-speculative accesses within hardware.

1 Introduction

The Transactional Memory (TM) abstraction is a synchronization mechanism that allows the programmer to optimistically execute sequences of shared-memory operations as atomic transactions. Several software TM designs [9, 26, 14, 12] have been introduced subsequent to the original TM proposal based in hardware [15]. The original dynamic STM implementation DSTM [14] ensures that a transaction aborts only if there is a read-write data conflict with a concurrent transaction (à la progressiveness [13]). However, to satisfy opacity [13], read operations in DSTM must incrementally validate the responses of all previous read operations to avoid inconsistent executions. This results in quadratic (in the size of the transaction’s read set) step-complexity for transactions. Subsequent STM implementations like NOrec [9] and TL2 [11] minimize the impact on performance due to incremental validation. NOrec uses a global sequence lock that is read at the start of a transaction and performs value-based validation during read operations only if the value of the global lock has been changed (by an updating transaction) since reading it. TL2, on the other hand, eliminates incremental validation completely. Like NOrec, it uses a global sequence lock, but each data item also has an associated sequence lock value that is updated alongside the data item. When a data item is read, if its associated sequence lock value is different from the value that was read from the sequence lock at the start of the transaction, then the transaction aborts.

In fact, STMs like TL2 and NOrec ensure progress in the absence of data conflicts with O(1) step complexity read operations and invisible reads (read operations which do not modify shared memory). Nonetheless, TM designs that are implemented entirely in software still incur significant performance overhead. Thus, current CPUs have included instructions to mark a block of memory accesses as transactional [24, 1, 18], allowing them to be executed atomically in hardware. Hardware transactions promise better performance than STMs, but they offer no progress guarantees since they may experience spurious aborts. This motivates the need for hybrid TMs in which the fast hardware transactions are complemented with slower software transactions that do not have spurious aborts.

To allow hardware transactions in a HyTM to detect conflicts with software transactions, hardware transactions must be instrumented to perform additional metadata accesses, which introduces overhead. Hardware transactions typically provide automatic conflict detection at cacheline granularity, thus ensuring that a transaction will be aborted if it experiences memory contention on a cacheline. This is at least the case with Intel’s Transactional Synchronization Extensions [27]. The IBM POWER8 architecture additionally allows hardware transactions to access metadata non-speculatively, thus bypassing automatic conflict detection. While this has the advantage of potentially reducing contention aborts in hardware, this makes the design of HyTM implementations potentially harder to prove correct.

In [3], it was shown that hardware transactions in opaque progressive HyTMs must perform at least one metadata access per transactional read and write. In this paper, we show that in opaque progressive HyTMs with invisible reads, software transactions cannot avoid incremental validation. Specifically, we prove that each read operation of a software transaction in a progressive HyTM must necessarily incur a validation cost that is linear in the size of the transaction’s read set. This is in contrast to TL2 which is progressive and has constant complexity read operations. Thus, in addition to the linear instrumentation cost in hardware transactions, there is a quadratic step complexity cost in software transactions.

We then present opaque HyTM algorithms providing progressiveness for a subset of transactions that are optimal in terms of hardware instrumentation. Algorithm 1 is progressive for all transactions, but it incurs high instrumentation overhead in practice. Algorithm 2 avoids all instrumentation in fast-path read operations, but is progressive only for slow-path reading transactions. We also sketch how some hardware instrumentation can be performed non-speculatively without violating opacity.

Extensive experiments were performed to characterize the cost of concurrency in practice. We studied the instrumentation-optimal algorithms, as well as TL2, Transactional Lock Elision (TLE) [23] and Hybrid NOrec [25] on both Intel and IBM POWER architectures. Each of the algorithms we studied contributes to an improved understanding of the concurrency vs. hardware instrumentation vs. software validation trade-offs for HyTMs. Comparing results between the very different Intel and IBM POWER architectures also led to new insights. Collectively, our results suggest the following. (i) The cost of concurrency is significant in practice; high hardware instrumentation impacts performance negatively on Intel and much more so on POWER8 due to its limited transactional cache capacity. (ii) It is important to implement HyTMs that provide progressiveness for a maximal set of transactions without incurring high hardware instrumentation overhead or using global contending bottlenecks. (iii) There is no easy way to derive more efficient HyTMs by taking advantage of non-speculative accesses supported within the fast-path in POWER8 processors.

Roadmap. The rest of the paper is organized as follows. $\mathcal{S}$ 2 presents details of the HyTM model that extends the model introduced in [3]. $\mathcal{S}$ 3 presents our main lower bound result on the step-complexity of slow-path transactions in progressive HyTMs while $\mathcal{S}$ 4 presents opaque HyTMs that are progressive for a subset of transactions. $\mathcal{S}$ 5 presents results from experiments on Intel Haswell and IBM POWER8 architectures which provide a clear characterization of the cost of concurrency in HyTMs, and study the impact of non-speculative (or direct) accesses within hardware transactions on performance. $\mathcal{S}$ 6 presents the related work along with concluding remarks. Formal proofs appear in the Appendix.

2 Hybrid transactional memory (HyTM)

Transactional memory (TM). A transaction is a sequence of transactional operations (or t-operations), reads and writes, performed on a set of transactional objects (t-objects). A TM implementation provides a set of concurrent processes with deterministic algorithms that implement reads and writes on t-objects using a set of base objects.

Configurations and executions. A configuration of a TM implementation specifies the state of each base object and each process. In the initial configuration, each base object has its initial value and each process is in its initial state. An event (or step) of a transaction invoked by some process is an invocation of a t-operation, a response of a t-operation, or an atomic primitive operation applied to base object along with its response. An execution fragment is a (finite or infinite) sequence of events $E=e_{1},e_{2},\dots$. An execution of a TM implementation $\mathcal{M}$ is an execution fragment where, informally, each event respects the specification of base objects and the algorithms specified by $\mathcal{M}$.

For any finite execution $E$ and execution fragment $E^{\prime}$, $E\cdot E^{\prime}$ denotes the concatenation of $E$ and $E^{\prime}$, and we say that $E\cdot E^{\prime}$ is an extension of $E$. For every transaction identifier $k$, $E|k$ denotes the subsequence of $E$ restricted to events of transaction $T_{k}$. If $E|k$ is non-empty, we say that $T_{k}$ participates in $E$, Let $\textit{txns}(E)$ denote the set of transactions that participate in $E$. Two executions $E$ and $E^{\prime}$ are indistinguishable to a set $\mathcal{T}$ of transactions, if for each transaction $T_{k}\in\mathcal{T}$, $E|k=E^{\prime}|k$. A transaction $T_{k}\in\textit{txns}(E)$ is complete in $E$ if $E|k$ ends with a response event. The execution $E$ is complete if all transactions in $\textit{txns}(E)$ are complete in $E$. A transaction $T_{k}\in\textit{txns}(E)$ is t-complete if $E|k$ ends with $A_{k}$ or $C_{k}$; otherwise, $T_{k}$ is t-incomplete. We consider the dynamic programming model: the read set (resp., the write set) of a transaction $T_{k}$ in an execution $E$, denoted $\textit{Rset}_{E}(T_{k})$ (resp., $\textit{Wset}_{E}(T_{k})$), is the set of t-objects that $T_{k}$ attempts to read (and resp. write) by issuing a t-read (resp., t-write) invocation in $E$ (for brevity, we sometimes omit the subscript $E$ from the notation).

We assume that base objects are accessed with read-modify-write (rmw) primitives. A rmw primitive event on a base object is trivial if, in any configuration, its application does not change the state of the object. Otherwise, it is called nontrivial. Events $e$ and $e^{\prime}$ of an execution $E$ contend on a base object $b$ if they are both primitives on $b$ in $E$ and at least one of them is nontrivial.

Hybrid transactional memory executions. We now describe the execution model of a Hybrid transactional memory (HyTM) implementation. In our HyTM model, shared memory configurations may be modified by accessing base objects via two kinds of primitives: direct and cached. (i) In a direct (also called non-speculative) access, the rmw primitive operates on the memory state: the direct-access event atomically reads the value of the object in the shared memory and, if necessary, modifies it. (ii) In a cached access performed by a process $i$, the rmw primitive operates on the cached state recorded in process $i$’s tracking set $\tau_{i}$.

More precisely, $\tau_{i}$ is a set of triples $(b,v,m)$ where $b$ is a base object identifier, $v$ is a value, and $m\in\{\mathit{shared},\mathit{exclusive}\}$ is an access mode. The triple $(b,v,m)$ is added to the tracking set when $i$ performs a cached rmw access of $b$, where $m$ is set to $\mathit{exclusive}$ if the access is nontrivial, and to $\mathit{shared}$ otherwise. We assume that there exists some constant $\mathit{TS}$ such that the condition $|\tau_{i}|\leq\mathit{TS}$ must always hold; this condition will be enforced by our model. A base object $b$ is present in $\tau_{i}$ with mode $m$ if $\exists v,(b,v,m)\in\tau_{i}$.

Hardware aborts. A tracking set can be invalidated by a concurrent process: if, in a configuration $C$ where $(b,v,\mathit{exclusive})\in\tau_{i}$ (resp., $(b,v,\mathit{shared})\in\tau_{i})$, a process $j\neq i$ applies any primitive (resp., any nontrivial primitive) to $b$, then $\tau_{i}$ becomes invalid and any subsequent event invoked by $i$ sets $\tau_{i}$ to $\emptyset$ and returns $\bot$. We refer to this event as a tracking set abort.

Any transaction executed by a correct process that performs at least one cached access must necessarily perform a cache-commit primitive that determines the terminal response of the transaction. A cache-commit primitive issued by process $i$ with a valid $\tau_{i}$ does the following: for each base object $b$ such that $(b,v,\mathit{exclusive})\in\tau_{i}$, the value of $b$ in $C$ is updated to $v$. Finally, $\tau_{i}$ is set to $\emptyset$ and the operation returns commit. We assume that a fast-path transaction $T_{k}$ returns $A_{k}$ as soon a cached primitive or cache-commit returns $\bot$.

Slow-path and fast-path transactions. We partition HyTM transactions into fast-path transactions and slow-path transactions. A slow-path transaction models a regular software transaction. An event of a slow-path transaction is either an invocation or response of a t-operation, or a direct rmw primitive on a base object. A fast-path transaction essentially encapsulates a hardware transaction. Specifically, in any execution $E$, we say that a transaction $T_{k}\in\mathord{\it txns}(E)$ is a fast-path transaction if $E|k$ contains at least one cached event. An event of a hardware transaction is either an invocation or response of a t-operation, or a direct trivial access or a cached access, or a cache-commit primitive.

Remark 1** (Tracking set aborts).**

*Let $T_{k}\in\mathord{\it txns}(E)$ be any t-incomplete fast-path transaction executed by process $i$, where $(b,v,\mathit{exclusive})\in\tau_{i}$ (resp., $(b,v,\mathit{shared})\in\tau_{i}$) after execution $E$, and $e$ be any event (resp., nontrivial event) that some process $j\neq i$ is poised to apply after $E$. The next event of $T_{k}$ in any extension of $E\cdot e$ is $A_{k}$. *

Remark 2** (Capacity aborts).**

Any cached access performed by a process $i$ executing a fast-path transaction $T_{k}$; $|\textit{Dset}(T_{k})|>1$ first checks the condition $|\tau_{i}|=\mathit{TS}$, where $\mathit{TS}$ is a pre-defined constant, and if so, it sets $\tau_{i}=\emptyset$ and immediately returns $\bot$.

Direct reads within fast-path. Note that we specifically allow hardware transactions to perform reads without adding the corresponding base object to the process’ tracking set, thus modeling the suspend/resume instructions supported by IBM POWER8 architectures. Note that Intel’s HTM does not support this feature: an event of a fast-path transaction does not include any direct access to base objects.

HyTM properties. We consider the TM-correctness property of opacity [13]: an execution $E$ is opaque if there exists a legal (every t-read of a t-object returns the value of its latest committed t-write) sequential execution $S$ equivalent to some t-completion of $E$ that respects the real-time ordering of transactions in $E$. We also assume a weak TM-liveness property for t-operations: every t-operation returns a matching response within a finite number of its own steps if running step-contention free from a configuration in which every other transaction is t-complete. Moreover, we focus on HyTMs that provide invisible reads: t-read operations do not perform nontrivial primitives in any execution.

3 Progressive HyTM must perform incremental validation

In this section, we show that it is impossible to implement opaque progressive HyTMs with invisible reads with $O$(1) step-complexity read operations for slow-path transactions. This result holds even if fast-path transactions may perform direct trivial accesses.

Formally, we say that a HyTM implementation $\mathcal{M}$ is progressive for a set $\mathcal{T}$ of transactions if in any execution $E$ of $\mathcal{M}$; $\mathcal{T}\subseteq\mathord{\it txns}(E)$, if any transaction $T_{k}\in\mathcal{T}$ returns $A_{k}$ in $E$, there exists another concurrent transaction $T_{m}$ that conflicts (both access the same t-object and at least one writes) with $T_{k}$ in $E$ [13].

We construct an execution of a progressive opaque HyTM in which every t-read performed by a read-only slow-path transaction must access linear (in the size of the read set) number of distinct base objects.

Theorem 3**.**

Let $\mathcal{M}$ be any progressive opaque HyTM implementation providing invisible reads. There exists an execution $E$ of $\mathcal{M}$ and some slow-path read-only transaction $T_{k}\in\mathord{\it txns}(E)$ that incurs a time complexity of $\Omega(m^{2})$; $m=|\textit{Rset}(T_{k})|$.

Proof sketch. We construct an execution of a read-only slow-path transaction $T_{\phi}$ that performs $m\in\mathbb{N}$ distinct t-reads of t-objects $X_{1},\ldots,X_{m}$. We show inductively that for each $i\in\{1,\ldots,m\}$; $m\in\mathbb{N}$, the $i^{\mathord{\it th}}$ t-read must access $i-1$ distinct base objects during its execution. The (partial) steps in our execution are depicted in Figure 1.

For each $i\in\{1,\ldots,m\}$, $\mathcal{M}$ has an execution of the form depicted in Figure 1(b). Start with the complete step contention-free execution of slow-path read-only transaction $T_{\phi}$ that performs $(i-1)$ t-reads: $\textit{read}_{\phi}(X_{1})\cdots\textit{read}_{\phi}(X_{i-1})$, followed by the t-complete step contention-free execution of a fast-path transaction $T_{i}$ that writes $nv_{i}\neq v_{i}$ to $X_{i}$ and commits and then the complete step contention-free execution fragment of $T_{\phi}$ that performs its $i^{th}$ t-read: $\textit{read}_{\phi}(X_{i})\rightarrow nv_{i}$. Indeed, by progressiveness, $T_{i}$ cannot incur tracking set aborts and since it accesses only a single t-object, it cannot incur capacity aborts. Moreover, in this execution, the t-read of $X_{i}$ by slow-path transaction $T_{\phi}$ must return the value $nv$ written by fast-path transaction $T_{i}$ since this execution is indistinguishable to $T_{\phi}$ from the execution in Figure 1(a).

We now construct $(i-1)$ different executions of the form depicted in Figure 1(c): for each $\ell\leq(i-1)$, a fast-path transaction $T_{\ell}$ (preceding $T_{i}$ in real-time ordering, but invoked following the $(i-1)$ t-reads by $T_{\phi}$) writes $nv_{\ell}\neq v$ to $X_{\ell}$ and commits, followed by the t-read of $X_{i}$ by $T_{\phi}$. Observe that, $T_{\ell}$ and $T_{i}$ which access mutually disjoint data sets cannot contend on each other since if they did, they would concurrently contend on some base object and incur a tracking set abort, thus violating progressiveness. Indeed, by the TM-liveness property we assumed (cf. Section 2) and invisible reads for $T_{\phi}$, each of these $(i-1)$ executions exist.

In each of these $(i-1)$ executions, the final t-read of $X_{i}$ cannot return the new value $nv$: the only possible serialization for transactions is $T_{\ell}$, $T_{i}$, $T_{\phi}$; but the $\textit{read}_{\phi}(X_{\ell})$ performed by $T_{k}$ that returns the initial value $v$ is not legal in this serialization—contradiction to the assumption of opacity. In other words, slow-path transaction $T_{\phi}$ is forced to verify the validity of t-objects in $\textit{Rset}(T_{\phi})$. Finally, we note that, for all $\ell,\ell^{\prime}\leq(i-1)$;$\ell^{\prime}\neq\ell$, fast-path transactions $T_{\ell}$ and $T_{\ell^{\prime}}$ access mutually disjoint sets of base objects thus forcing the t-read of $X_{i}$ to access least $i-1$ different base objects in the worst case. Consequently, for all $i\in\{2,\ldots,m\}$, slow-path transaction $T_{\phi}$ must perform at least $i-1$ steps while executing the $i^{th}$ t-read in such an execution. $\Box$

How STM implementations mitigate the quadratic lower bound step complexity. NOrec [9] is a progressive opaque STM that minimizes the average step-complexity resulting from incremental validation of t-reads. Transactions read a global versioned lock at the start, and perform value-based validation during t-read operations iff the global version has changed. TL2 [11] improves over NOrec by circumventing the lower bound of Theorem 3. Concretely, TL2 associates a global version with each t-object updated during a transaction and performs validation with O(1) complexity during t-reads by simply verifying if the version of the t-object is greater than the global version read at the start of the transaction. Technically, NOrec and algorithms in this paper provide a stronger definition of progressiveness: a transaction may abort only if there is a prefix in which it conflicts with another transaction and both are t-incomplete. TL2 on the other hand allows a transaction to abort due to a concurrent conflicting transaction.

Implications for disjoint-access parallelism in HyTM. The property of disjoint-access parallelism (DAP), in its weakest form, ensures that two transactions concurrently contend on the same base object only if their data sets are connected in the conflict graph, capturing data-set overlaps among all concurrent transactions [5]. It is well known that weak DAP STMs with invisible reads must perform incremental validation even if the required TM-progress condition requires transactions to commit only in the absence of any concurrent transaction [13, 17]. For example, DSTM [14] is a weak DAP STM that is progressive and consequently incurs the validation complexity. On the other hand, TL2 and NOrec are not weak DAP since they employ a global versioned lock that mitigates the cost of incremental validation, but this allows two transactions accessing disjoint data sets to concurrently contend on the same memory location. Indeed, this inspires the proof of Theorem 3.

4 Hybrid transactional memory algorithms

Instrumentation-optimal progressive HyTM. We describe a HyTM algorithm that is a tight bound for Theorem 3 and the instrumentation cost on the fast-path transactions established in [3]. Pseudocode appears in Algorithm 1. For every t-object $X_{j}$, our implementation maintains a base object $v_{j}$ that stores the value of $X_{j}$ and a sequence lock $r_{j}$.

Fast-path transactions: For a fast-path transaction $T_{k}$ executed by process $p_{i}$, the $\textit{read}_{k}(X_{j})$ implementation first reads $r_{j}$ (direct) and returns $A_{k}$ if some other process $p_{j}$ holds a lock on $X_{j}$. Otherwise, it returns the value of $X_{j}$. As with $\textit{read}_{k}(X_{j})$, the $\textit{write}(X_{j},v)$ implementation returns $A_{k}$ if some other process $p_{j}$ holds a lock on $X_{j}$; otherwise process $p_{i}$ increments the sequence lock $r_{j}$. If the cache has not been invalidated, $p_{i}$ updates the shared memory during $\textit{tryC}_{k}$ by invoking the $\mathord{\it commit-cache}$ primitive.

Slow-path read-only transactions: Any $\textit{read}_{k}(X_{j})$ invoked by a slow-path transaction first reads the value of the t-object from $v_{j}$, adds $r_{j}$ to $\textit{Rset}(T_{k})$ if its not held by a concurrent transaction and then performs validation on its entire read set to check if any of them have been modified. If either of these conditions is true, the transaction returns $A_{k}$. Otherwise, it returns the value of $X_{j}$. Validation of the read set is performed by re-reading the values of the sequence lock entries stored in $\textit{Rset}(T_{k})$.

Slow-path updating transactions: An updating slow-path transaction $T_{k}$ attempts to obtain exclusive write access to its entire write set. If all the locks on the write set were acquired successfully, $T_{k}$ performs validation of the read set and if successful, updates the values of the t-objects in shared memory, releases the locks and returns $C_{k}$; else $p_{i}$ aborts the transaction.

Direct accesses inside fast-path: Note that opacity is not violated even if the accesses of the sequence lock during t-read may be performed directly without incurring tracking set aborts.

Instrumentation-optimal HyTM that is progressive only for slow-path reading transactions. Algorithm 2 does not incur the linear instrumentation cost on the fast-path reading transactions (inherent to Algorithm 1), but provides progressiveness only for slow-path reading transactions. The instrumentation cost on fast-path t-reads is avoided by using a global lock that serializes all updating slow-path transactions during the $\textit{tryC}_{k}$ procedure. Fast-path transactions simply check if this lock is held without acquiring it (similar to TLE [23]). While the per-read instrumentation overhead is avoided, Algorithm 2 still incurs the per-write instrumentation cost.

Sacrificing progressiveness and minimizing contention window. Observe that the lower bound in Theorem 3 assumes progressiveness for both slow-path and fast-path transactions along with opacity and invisible reads. Note that Algorithm 2 retains the validation step complexity cost since it provides progressiveness for slow-path readers.

Hybrid NOrec [8] is a HyTM implementation that does not satisfy progressiveness (unlike its STM counterpart NOrec), but mitigates the step-complexity cost on slow-path transactions by performing incremental validation during a transactional read iff the shared memory has changed since the start of the transaction. Conceptually, Hybrid NOrec uses a global sequence lock gsl that is incremented at the start and end of each transaction’s commit procedure. Readers can use the value of gsl to determine whether shared memory has changed between two configurations. Unfortunately, with this approach, two fast path transactions will always conflict on the gsl if their commit procedures are concurrent. To reduce the contention window for fast path transactions, the gsl is actually implemented as two separate locks (the second one called esl). A slow-path transaction locks both esl and gsl while it is committing. Instead of incrementing gsl, a fast path transaction checks if esl is locked and aborts if it is. Then, at the end of the fast path transaction’s commit procedure, it increments gsl twice (quickly locking and releasing it and immediately commits in hardware). Although the window for fast path transactions to contend on gsl is small, our experiments have shown that contention on gsl has a significant impact on performance.

5 Evaluation

In this section, we study the performance characteristics of Algorithms 1 and 2, Hybrid NOrec, TLE and TL2. Our experimental goals are: (G1) to study the performance impact of instrumentation on the fast-path and validation on the slow-path, (G2) to understand how HyTM algorithm design affects performance with Intel and IBM POWER8 HTMs, and (G3) to determine whether direct accesses can be used to obtain performance improvements on IBM POWER8 using the supported suspend/resume instruction to escape from a hardware transaction.

Experimental system (Intel). The experimental system is a 2-socket Intel E7-4830 v3 with 12 cores per socket and 2 hyperthreads (HTs) per core, for a total of 48 threads. Each core has a private 32KB L1 cache and 256KB L2 cache (shared between HTs on a core). All cores on a socket share a 30MB L3 cache. This system has a non-uniform memory architecture (NUMA) in which threads have significantly different access costs to different parts of memory depending on which processor they are currently executing on. The machine has 128GB of RAM, and runs Ubuntu 14.04 LTS. All code was compiled with the GNU C++ compiler (G++) 4.8.4 with build target x86_64-linux-gnu and compilation options -std=c++0x -O3 -mx32.

We pin threads so that the first socket is saturated before we place any threads on the second socket. Thus, thread counts 1-24 run on a single socket. Furthermore, hyperthreading is engaged on the first socket for thread counts 13-24, and on the second socket for thread counts 37-48. Consequently, our graphs clearly show the effects of NUMA and hyperthreading.

Experimental system (IBM POWER8). The experimental system is a IBM S822L with 2x 12-core 3.02GHz processor cards, 128GB of RAM, running Ubuntu 16.04 LTS. All code was compiled using G++ 5.3.1. This is a dual socket machine, and each socket has two NUMA zones. It is expensive to access memory on a different NUMA zone, and even more expensive if the NUMA zone is on a different socket. POWER8 uses the L2 cache for detecting tracking set aborts, and limits the size of a transaction’s read- and write-set to 8KB each [21]. This is in contrast to Intel which tracks conflicts on the entire L3 cache, and only limits a transaction’s read-set to the L3 cache size, and its write-set to the L1 cache size.

We pin one thread on each core within a NUMA zone before moving to the next zone. We remark that unlike the thread pinning policy for Intel which saturated the first socket before moving to the next, this proved to be the best policy for POWER8 which experiences severe negative scaling when threads are saturated on a single 8-way hardware multi-threaded core. This is because all threads on a core share resources, including the L1 and L2 cache, a single branch execution pipeline, and only two load-store pipelines.

Hybrid TM implementations. For TL2, we used the implementation published by its authors. We implemented the other algorithms in C++. Each hybrid TM algorithm first attempts to execute a transaction on the fast-path, and will continue to execute on the fast-path until the transaction has experienced 20 aborts, at which point it will fall back to the slow-path. We implemented Algorithm 1 on POWER8 where each read of a sequence lock during a transactional read operation was enclosed within a pair of suspend/resume instructions to access them without incurring tracking set aborts (Algorithm 1$\ast$). We remark that this does not affect the opacity of the implementation. We also implemented the variant of Hybrid NOrec (Hybrid NOrec$\ast$) in which the update to gsl is performed using a fetch-increment primitive between suspend/resume instructions, as is recommended in [25].

In each algorithm, instead of placing a lock next to each address in memory, we allocated a global array of one million locks, and used a simple hash function to map each address to one of these locks. This avoids the problem of having to change a program’s memory layout to incorporate locks, and greatly reduces the amount of memory needed to store locks, at the cost of some possible false conflicts since many addresses map to each lock. Note that the exact same approach was taken by the authors of TL2.

We chose not to compile the hybrid TMs as separate libraries, since invoking library functions for each read and write can cause algorithms to incur enormous overhead. Instead, we compiled each hybrid TM directly into the code that uses it.

Experimental methodology. We used a simple unbalanced binary search tree (BST) microbenchmark as a vehicle to study the performance of our implementations. The BST implements a dictionary, which contains a set of keys, each with an associated value. For each TM algorithm and update rate $U\in\{40,10,0\}$, we run six timed trials for several thread counts $n$. Each trial proceeds in two phases: prefilling and measuring. In the prefilling phase, $n$ concurrent threads perform 50% Insert and 50% Delete operations on keys drawn uniformly randomly from $[0,10^{5})$ until the size of the tree converges to a steady state (containing approximately $10^{5}/2$ keys). Next, the trial enters the measuring phase, during which threads begin counting how many operations they perform. In this phase, each thread performs $(U/2)$% Insert, $(U/2)$% Delete and $(100-U)$% Search operations, on keys/values drawn uniformly from $[0,10^{5})$, for one second.

Uniformly random updates to an unbalanced BST have been proven to yield trees of logarithmic height with high probability. Thus, in this type of workload, almost all transactions succeed in hardware, and the slow-path is almost never used. To study performance when transactions regularly run on slow-path, we introduced an operation called a RangeIncrement that often fails in hardware and must run on the slow-path. A RangeIncrement$(low,hi)$ atomically increments the values associated with each key in the range $[low,hi]$ present in the tree. Note that a RangeIncrement is more likely to experience data conflicts and capacity aborts than BST updates, which only modify a single node.

We consider two types of workloads: (W1) all $n$ threads perform Insert, Delete and Search, and (W2) $n-1$ threads perform Insert, Delete and Search and one thread performs only RangeIncrement operations. Figure 3 shows the results for both types of workloads.

Results (Intel). We first discuss the 0% updates graph for workload type W1. In this graph, essentially all operations committed in hardware. In fact, in each trial, a small fraction of 1% of operations ran on the slow-path. Thus, any performance differences shown in the graph are essentially differences in the performance of the algorithms’ respective fast-paths (with the exception of TL2). Algorithm 1, which has instrumentation in its fast-path read operations, has significantly lower performance than Algorithm 2, which does not. Since this is a read-only workload, this instrumentation is responsible for the performance difference.

In the W1 workloads, TLE, Algorithm 2 and Hybrid NOrec perform similarly (with a small performance advantage for Hybrid NOrec at high thread counts). This is because the fast-paths for these three algorithms have similar amounts of instrumentation: there is no instrumentation for reads or writes, and the transaction itself incurs one or two metadata accesses. In contrast, in the W2 workloads, TLE performs quite poorly, compared to the HyTM algorithms. In these workloads, transactions must periodically run on the slow-path, and in TLE, this entails acquiring a global lock that restricts progress for all other threads. At high thread counts this significantly impacts performance. Its performance decreases as the sizes of the ranges passed to RangeIncrement increase. Its performance is also negatively impacted by NUMA effects at thread counts higher than 24. (This is because, when a thread $p$ reads the lock and incurs a cache miss, if the lock was last held by another thread on the same socket, then $p$ can fill the cache miss by loading it from the shared L3 cache. However, if the lock was last held by a thread on a different socket, then $p$ must read the lock state from main memory, which is significantly more expensive.) On the other hand, in each graph in the W2 workloads, the performance of each HyTM (and TL2) is similar to its performance in the corresponding W1 workload graph. For Algorithm 1 (and TL2), this is because of progressiveness. Although Algorithm 2 is not truly progressive, fast-path transactions will abort only if they are concurrent with the commit procedure of a slow-path transaction. In RangeIncrement operations, there is a long read-only prefix (which is exceptionally long because of Algorithm 2’s quadratic validation) followed by a relatively small set of writes. Thus, RangeIncrement operations have relatively little impact on the fast-path. The explanation is similar for Hybrid NOrec (except that it performs less validation than Algorithm 2).

Observe that the performance of Hybrid NOrec decreases slightly, relative to Algorithm 2, after 24 threads. Recall that, in Hybrid NOrec, the global sequence number is a single point of contention on the fast-path. (In Algorithm 2, the global lock is only modified by slow-path transactions, so fast-path transactions do not have a single point of contention.) We believe this is due to NUMA effects, similar to those described in [6]. Specifically, whenever a threads on the first socket performs a fast-path transaction that commits and modifies the global lock, it causes cache invalidations for all other threads. Threads on socket two must then load the lock state from main memory, which takes much longer than loading it from the shared L3 cache. This lengthens the transaction’s window of contention, making it more likely to abort. (In the 0% updates graph in the W2 workload, we still see this effect, because there is a thread performing RangeIncrement operations.)

Results (IBM POWER8). Algorithm 1 performs poorly on POWER8: POWER8 transactions can only load 64 cache lines before they will abort [22]. Transactions read locks and tree nodes, which are in different cache lines: together, they often exceed 64 cache lines loaded in a tree operation, so most transactions cannot succeed in hardware. Consequently, on POWER8, it is incredibly important either to have minimal instrumentation in transactions, or for metadata to be located in the same cache lines as program data. Of course, the latter is not possible for HyTMs, which do not have control over the layout of program data. Consequently, Algorithm 2 outperforms Algorithm 1 in POWER8 quite easily by avoiding the per-read instrumentation.

Algorithm 1 is improved slightly by the expensive (on POWER8) suspend/resume on sequence locks during transactional reads, but it still performs relatively poorly. To make suspend/resume a practical tool, one could imagine attempting to collect several metadata accesses and perform them together to amortize the cost of a suspend/resume pair. For instance, in Algorithm 1, one might try to update the locks for all of the transactional writes at once, when the transaction commits. Typically one would accomplish this by logging all writes so that a process can remember which addresses it must lock at commit time. However, logging the writes inside the transaction would be at least as costly as just performing them.

Observe that Hybrid NOrec does far worse with updates in POWER8 than on the Intel machine. This is due to the fact that fetch-increment on a single location experiences severe negative scaling on the POWER8 processor: e.g., in one second, a single thread can perform 37 fetch-add operations while 6 threads perform a total of 9 million and 24 threads perform only 4 million fetch-add operations. In contrast, the Intel machine performs 32 million operations with 6 threads and 45 million with 24 threads. This is likely because this Intel processor provides fetch-add instructions while it must be emulated on the POWER8 processor.

In Hybrid NOrec$\ast$, the non-speculative increment of gsl actually makes performance worse. Recall that in Hybrid NOrec, if a fast-path transaction $T_{1}$ increments gsl, and then a software transaction $T_{2}$ reads gsl (as part of validation) before $T_{1}$ commits, then $T_{1}$ will abort, and $T_{2}$ will not see $T_{1}$’s change to gsl. So, $T_{2}$ will have a higher chance of avoiding incremental validation (and, hence, will likely take less time to run, and have a smaller contention window). However, in Hybrid NOrec$\ast$, once $T_{1}$ increments gsl, $T_{2}$ will see the change to gsl, regardless of whether $T_{1}$ commits or aborts. Thus, $T_{2}$ will be forced to perform incremental validation. In our experiments, we observed that a much larger number of transactions ran on the fallback path in Hybrid NOrec$\ast$ than in Hybrid NOrec (often several orders of magnitude more).

6 Related work and discussion

HyTM implementations and complexity. Early HyTMs like the ones described in [10, 16] provided progressiveness, but subsequent HyTM proposals like PhTM [19] and HybridNOrec [8] sacrificed progressiveness for lesser instrumentation overheads. However, the clear trade-off in terms of concurrency vs. instrumentation for these HyTMs have not been studied in the context of currently available HTM architectures. This instrumentation cost on the fast-path was precisely characterized in [3]. In this paper, we proved the inherent cost of concurrency on the slow-path thus establishing a surprising, but intuitive complexity separation between progressive STMs and HyTMs. Moreover, to the best of our knowledge, this is the first work to consider the theoretical foundations of the cost of concurrency in HyTMs in theory and practice (on currently available HTM architectures). Proof of Theorem 3 is based on the analogous proof for step complexity of STMs that are disjoint-access parallel [17, 13]. Our implementation of Hybrid NOrec follows [25], which additionally proposed the use of direct accesses in fast-path transactions to reduce instrumentation overhead in the AMD Advanced Synchronization Facility (ASF) architecture.

Beyond the two path HyTM approach. Employing an uninstrumented fast fast-path. We now describe how every transaction may first be executed in a “fast” fast-path with almost no instrumentation and if unsuccessful, may be re-attempted in the fast-path and subsequently in slow-path. Specifically, we transform any opaque HyTM $\mathcal{M}$ to an opaque HyTM $\mathcal{M}^{\prime}$ in which a shared fetch-and-add metadata base object $F$ that slow-path updating transactions increment (and resp. decrement) at the start (and resp. end). In $\mathcal{M}^{\prime}$, a “fast” fast-path transaction checks first if $F$ is [math] and if not, aborts the transaction; otherwise the transaction is continued as an uninstrumented hardware transaction. The code for the fast-path and the slow-path is identical to $\mathcal{M}$.

Other approaches. Recent work has investigated fallback to reduced hardware transactions [20] in which an all-software slow-path is augmented using a slightly faster slow-path that is optimistically used to avoid running some transactions on the true software-only slow-path. Amalgamated lock elision (ALE) was proposed in [2] which improves over TLE by executing the slow-path as a series of segments, each of which is a dynamic length hardware transaction. Invyswell [7] is a HyTM design with multiple hardware and software modes of execution that gives flexibility to avoid instrumentation overhead in uncontended executions.

We remark that such multi-path approaches may be easily applied to each of the Algorithms proposed in this paper. However, in the search for an efficient HyTM, it is important to strike the fine balance between concurrency, hardware instrumentation and software validation cost. Our lower bound, experimental methodology and evaluation of HyTMs provides the first clear characterization of these trade-offs in both Intel and POWER8 architectures.

Appendix A Proof of opacity for algorithms

We will prove the opacity of Algorithm 1 even if some of accesses performed by fast-path transactions are direct (as indicated in the pseudocode). Analogous arguments apply to Algorithm 2.

Let $E$ by any execution of Algorithm 1. Since opacity is a safety property, it is sufficient to prove that every finite execution is opaque [4]. Let $<_{E}$ denote a total-order on events in $E$.

Let $H$ denote a subsequence of $E$ constructed by selecting linearization points of t-operations performed in $E$. The linearization point of a t-operation $op$, denoted as $\ell_{op}$ is associated with a base object event or an event performed during the execution of $op$ using the following procedure.

Completions. First, we obtain a completion of $E$ by removing some pending invocations or adding responses to the remaining pending invocations. Incomplete $\textit{read}_{k}$, $\textit{write}_{k}$ operation performed by a slow-path transaction $T_{k}$ is removed from $E$; an incomplete $\textit{tryC}_{k}$ is removed from $E$ if $T_{k}$ has not performed any write to a base object $r_{j}$; $X_{j}\in\textit{Wset}(T_{k})$ in Line LABEL:line:write, otherwise it is completed by including $C_{k}$ after $E$. Every incomplete $\textit{read}_{k}$, $\textit{tryA}_{k}$, $\textit{write}_{k}$ and $\textit{tryC}_{k}$ performed by a fast-path transaction $T_{k}$ is removed from $E$.

Linearization points. Now a linearization $H$ of $E$ is obtained by associating linearization points to t-operations in the obtained completion of $E$. For all t-operations performed a slow-path transaction $T_{k}$, linearization points as assigned as follows:

• •

For every t-read $op_{k}$ that returns a non-Ak value, $\ell_{op_{k}}$ is chosen as the event in Line LABEL:line:read2 of Algorithm 1, else, $\ell_{op_{k}}$ is chosen as invocation event of $op_{k}$

• •

For every $op_{k}=\textit{write}_{k}$ that returns, $\ell_{op_{k}}$ is chosen as the invocation event of $op_{k}$

• •

For every $op_{k}=\textit{tryC}_{k}$ that returns $C_{k}$ such that $\textit{Wset}(T_{k})\neq\emptyset$, $\ell_{op_{k}}$ is associated with the first write to a base object performed by $\mathord{\sf release}$ when invoked in Line LABEL:line:rel, else if $op_{k}$ returns $A_{k}$, $\ell_{op_{k}}$ is associated with the invocation event of $op_{k}$

• •

For every $op_{k}=\textit{tryC}_{k}$ that returns $C_{k}$ such that $\textit{Wset}(T_{k})=\emptyset$, $\ell_{op_{k}}$ is associated with Line LABEL:line:return

For all t-operations performed a fast-path transaction $T_{k}$, linearization points are assigned as follows:

• •

For every t-read $op_{k}$ that returns a non-Ak value, $\ell_{op_{k}}$ is chosen as the event in Line LABEL:line:lin1 of Algorithm 1, else, $\ell_{op_{k}}$ is chosen as invocation event of $op_{k}$

• •

For every $op_{k}$ that is a $\textit{tryC}_{k}$, $\ell_{op_{k}}$ is the $\mathord{\it commit-cache}_{k}$ primitive invoked by $T_{k}$

• •

For every $op_{k}$ that is a $\textit{write}_{k}$, $\ell_{op_{k}}$ is the event in Line LABEL:line:lin2.

$<_{H}$ denotes a total-order on t-operations in the complete sequential history $H$.

Serialization points. The serialization of a transaction $T_{j}$, denoted as $\delta_{T_{j}}$ is associated with the linearization point of a t-operation performed by the transaction.

We obtain a t-complete history ${\bar{H}}$ from $H$ as follows. A serialization $S$ is obtained by associating serialization points to transactions in ${\bar{H}}$ as follows: for every transaction $T_{k}$ in $H$ that is complete, but not t-complete, we insert $\textit{tryC}_{k}\cdot A_{k}$ immediately after the last event of $T_{k}$ in $H$. If $T_{k}$ is an updating transaction that commits, then $\delta_{T_{k}}$ is $\ell_{\textit{tryC}_{k}}$. If $T_{k}$ is a read-only or aborted transaction, then $\delta_{T_{k}}$ is assigned to the linearization point of the last t-read that returned a non-Ak value in $T_{k}$.

$<_{S}$ denotes a total-order on transactions in the t-sequential history $S$. Since for a given transaction, its serialization point is chosen between the first and last event of the transaction, if $T_{i}\prec_{H}T_{j}$, then $\delta_{T_{i}}<_{E}\delta_{T_{j}}$ implies $T_{i}<_{S}T_{j}$.

Throughout this proof, we consider that process $p_{i}$ executing fast-path transaction $T_{k}\in\mathord{\it txns}(E)$ does not include the sequence lock $r_{j}$ in the tracking set of $p_{i}$ when accessed in Line LABEL:line:hread during $\textit{read}_{k}(X_{j})$.

Claim 4**.**

If every transaction $T_{k}\in\mathord{\it txns}(E)$ is fast-path, then $S$ is legal.

Proof.

Recall that Algorithm 1 performs direct accesses only during the t-read operation in Line LABEL:line:hread which involves reading the sequence lock $r_{j}$ corresponding to t-object $X_{j}$. However, any two fast-path transactions accessing conflicting data sets must necessarily incur a tracking abort (cf. Remark 1) in $E$. It follows immediately that $S$ must be legal. ∎

Claim 5**.**

$S$* is legal, i.e., every t-read returns the value of the latest committed t-write in $S$.*

Proof.

We claim that for every $\textit{read}_{j}(X_{m})\rightarrow v$, there exists some slow-path transaction $T_{i}$ (or resp. fast-path) that performs $\textit{write}_{i}(X_{m},v)$ and completes the event in Line LABEL:line:write (or resp. Line LABEL:line:lin2) such that $\textit{read}_{j}(X_{m})\not\prec_{H}^{RT}\textit{write}_{i}(X_{m},v)$.

Suppose that $T_{i}$ is a slow-path transaction: since $\textit{read}_{j}(X_{m})$ returns the response $v$, the event in Line LABEL:line:read2 succeeds the event in Line LABEL:line:write performed by $\textit{tryC}_{i}$. Since $\textit{read}_{j}(X_{m})$ can return a non-abort response only after $T_{i}$ releases the lock on $r_{m}$ in Line LABEL:line:rel1, $T_{i}$ must be committed in $S$. Consequently, $\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{read}_{j}(X_{m})}$. Since, for any updating committing transaction $T_{i}$, $\delta_{T_{i}}=\ell_{\textit{tryC}_{i}}$, it follows that $\delta_{T_{i}}<_{E}\delta_{T_{j}}$.

Otherwise if $T_{i}$ is a fast-path transaction, then clearly $T_{i}$ is a committed transaction in $S$. Recall that $\textit{read}_{j}(X_{m})$ can read $v$ during the event in Line LABEL:line:read2 only after $T_{i}$ applies the $\mathord{\it commit-cache}$ primitive. By the assignment of linearization points, $\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{read}_{j}(X_{m})}$ and thus, $\delta_{T_{i}}<_{E}\ell_{\textit{read}_{j}(X_{m})}$.

Thus, to prove that $S$ is legal, it suffices to show that there does not exist a transaction $T_{k}$ that returns $C_{k}$ in $S$ and performs $\textit{write}_{k}(X_{m},v^{\prime})$; $v^{\prime}\neq v$ such that $T_{i}<_{S}T_{k}<_{S}T_{j}$.

$T_{i}$ and $T_{k}$ are both updating transactions that commit. Thus, ($T_{i}<_{S}T_{k}$) $\Longleftrightarrow$ ($\delta_{T_{i}}<_{E}\delta_{T_{k}}$) and ($\delta_{T_{i}}<_{E}\delta_{T_{k}}$) $\Longleftrightarrow$ ($\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{tryC}_{k}}$).

Since, $T_{j}$ reads the value of $X$ written by $T_{i}$, one of the following is true: $\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{tryC}_{k}}<_{E}\ell_{\textit{read}_{j}(X_{m})}$ or $\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{read}_{j}(X_{m})}<_{E}\ell_{\textit{tryC}_{k}}$.

Suppose that $\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{tryC}_{k}}<_{E}\ell_{\textit{read}_{j}(X_{m})}$.

(Case I:) $T_{i}$ and $T_{k}$ are slow-path transactions.

Thus, $T_{k}$ returns a response from the event in Line LABEL:line:acq before the read of the base object associated with $X_{m}$ by $T_{j}$ in Line LABEL:line:read2. Since $T_{i}$ and $T_{k}$ are both committed in $E$, $T_{k}$ returns true from the event in Line LABEL:line:acq only after $T_{i}$ releases $r_{m}$ in Line LABEL:line:rel1.

If $T_{j}$ is a slow-path transaction, recall that $\textit{read}_{j}(X_{m})$ checks if $X_{j}$ is locked by a concurrent transaction, then performs read-validation (Line LABEL:line:abort0) before returning a matching response. Indeed, $\textit{read}_{j}(X_{m})$ must return $A_{j}$ in any such execution.

If $T_{j}$ is a fast-path transaction, it follows that $\textit{read}_{j}(X_{m})$ must return $A_{j}$ immediately from Remark 1.

Thus, $\ell_{\textit{tryC}_{i}}<_{E}\ell_{\textit{read}_{j}(X)}<_{E}\ell_{\textit{tryC}_{k}}$.

(Case II:) $T_{i}$ is a slow-path transaction and $T_{k}$ is a fast-path transaction. Thus, $T_{k}$ returns $C_{k}$ before the read of the base object associated with $X_{m}$ by $T_{j}$ in Line LABEL:line:read2, but after the response of acquire by $T_{i}$ in Line LABEL:line:acq. Since $\textit{read}_{j}(X_{m})$ reads the value of $X_{m}$ to be $v$ and not $v^{\prime}$, $T_{i}$ performs the cas to $v_{m}$ in Line LABEL:line:write after the $T_{k}$ performs the $\mathord{\it commit-cache}$ primitive (since if otherwise, $T_{k}$ would be aborted in $E$). But then the cas on $v_{m}$ performed by $T_{i}$ would return $\mathit{false}$ and $T_{i}$ would return $A_{i}$—contradiction.

(Case III:) $T_{k}$ is a slow-path transaction and $T_{i}$ is a fast-path transaction. This is analogous to the above case.

(Case IV:) $T_{i}$ and $T_{k}$ are fast-path transactions. Follows immediately from Claim 4.

We now need to prove that $\delta_{T_{j}}$ indeed precedes $\ell_{\textit{tryC}_{k}}$ in $E$. Consider the two possible cases. Suppose that $T_{j}$ is a read-only transaction. Then, $\delta_{T_{j}}$ is assigned to the last t-read performed by $T_{j}$ that returns a non-Aj value. If $\textit{read}_{j}(X_{m})$ is not the last t-read that returned a non-Aj value, then there exists a $\textit{read}_{j}(X^{\prime})$ such that $\ell_{\textit{read}_{j}(X_{m})}<_{E}\ell_{\textit{tryC}_{k}}<_{E}\ell_{read_{j}(X^{\prime})}$. But then this t-read of $X^{\prime}$ must abort by performing the checks in Line LABEL:line:abort0 or incur a tracking set abort—contradiction.

Otherwise suppose that $T_{j}$ is an updating transaction that commits, then $\delta_{T_{j}}=\ell_{\textit{tryC}_{j}}$ which implies that $\ell_{read_{j}(X)}<_{E}\ell_{\textit{tryC}_{k}}<_{E}\ell_{\textit{tryC}_{j}}$. Then, $T_{j}$ must neccesarily perform the checks in Line LABEL:line:abort3 and return $A_{j}$ or incur a tracking set abort—contradiction to the assumption that $T_{j}$ is a committed transaction.∎

Since $S$ is legal and respects the real-time ordering of transactions, Algorithm 1 is opaque.

Appendix B Proof of Theorem 3

The proof of the lemma below is a simple extension of the analogous lemma from [3] allowing direct trivial accesses inside fast-path transactions which in turn is inspired by an analogous result concerning disjoint-access parallel STMs [5]. Intuitively, the proof follows follows from the fact that the tracking set of a process executing a fast-path transaction is invalidated due to contention on a base object with another transaction (cf. Remark 1).

Lemma 6**.**

Let $\mathcal{M}$ be any progressive HyTM implementation in which fast-path transactions may perform trivial direct accesses. Let $E_{1}\cdot E_{2}$ be an execution of $\mathcal{M}$ where $E_{1}$ (and resp. $E_{2}$) is the step contention-free execution fragment of transaction $T_{1}$ (and resp. $T_{2}$) executed by process $p_{1}$ (and resp. $p_{2}$), $T_{1}$ and $T_{2}$ do not conflict in $E_{1}\cdot E_{2}$, and at least one of $T_{1}$ or $T_{2}$ is a fast-path transaction. Then, $T_{1}$ and $T_{2}$ do not contend on any base object in $E_{1}\cdot E_{2}$.

Proof.

Suppose, by contradiction that $T_{1}$ and $T_{2}$ contend on the same base object in $E_{1}\cdot E_{2}$.

If in $E_{1}$, $T_{1}$ performs a nontrivial event on a base object on which they contend, let $e_{1}$ be the last event in $E_{1}$ in which $T_{1}$ performs such an event to some base object $b$ and $e_{2}$, the first event in $E_{2}$ that accesses $b$ (note that by assumption, $e_{1}$ is a direct access). Otherwise, $T_{i}$ only performs trivial events in $E_{1}$ to base objects (some of which may be direct) on which it contends with $T_{2}$ in $E_{1}\cdot E_{2}$: let $e_{2}$ be the first event in $E_{2}$ in which $E_{2}$ performs a nontrivial event to some base object $b$ on which they contend and $e_{1}$, the last event of $E_{1}$ in $T_{1}$ that accesses $b$.

Let $E_{1}^{\prime}$ (and resp. $E_{2}^{\prime}$) be the longest prefix of $E_{1}$ (and resp. $E_{2}$) that does not include $e_{1}$ (and resp. $e_{2}$). Since before accessing $b$, the execution is step contention-free for $T_{1}$, $E\cdot E_{1}^{\prime}\cdot E_{2}^{\prime}$ is an execution of $\mathcal{M}$. By assumption of lemma, $T_{1}$ and $T_{2}$ do not conflict in $E_{1}^{\prime}\cdot E_{2}^{\prime}$. By construction, $E_{1}\cdot E_{2}^{\prime}$ is indistinguishable to $T_{2}$ from $E_{1}^{\prime}\cdot E_{2}^{\prime}$. Hence, $T_{1}$ and $T_{2}$ are poised to apply contending events $e_{1}$ and $e_{2}$ on $b$ in the execution $\tilde{E}=E_{1}^{\prime}\cdot E_{2}^{\prime}$.

We now consider two cases:

($e_{1}$ is a nontrivial event) After $\tilde{E}\cdot e_{1}$, $b$ is contained in the tracking set of process $p_{1}$ in exclusive mode and in the extension $\tilde{E}\cdot e_{1}\cdot e_{2}$, we have that $\tau_{1}$ is invalidated. Thus, by Remark 1, transaction $T_{1}$ must return $A_{1}$ in any extension of $E\cdot e_{1}\cdot e_{2}$—a contradiction to the assumption that $\mathcal{M}$ is progressive. 2. 2.

($e_{1}$ is a trivial event) Recall that $e_{1}$ may be potentially an event involving a direct access. Consider the execution $\tilde{E}\cdot e_{2}$ following which $b$ is contained in the tracking set of process $p_{2}$ in exclusive mode. Clearly, we have an extension $\tilde{E}\cdot e_{2}\cdot e_{1}$ in which $\tau_{2}$ is invalidated. Thus transaction $T_{2}$ must return $A_{2}$ in any extension of $E\cdot e_{2}\cdot e_{1}$—a contradiction to the assumption that $\mathcal{M}$ is progressive.

∎

Theorem 7**.**

Let $\mathcal{M}$ be any progressive opaque HyTM implementation providing invisible reads. There exists an execution $E$ of $\mathcal{M}$ and some slow-path read-only transaction $T_{k}\in\mathord{\it txns}(E)$ that incurs a time complexity of $\Omega(m^{2})$; $m=|\textit{Rset}(T_{k})|$.

Proof.

For all $i\in\{1,\ldots,m\}$; $m\in\mathbb{N}$, let $v$ be the initial value of t-object $X_{i}$. Let $\pi^{m}$ denote the complete step contention-free execution of a slow-path transaction $T_{\phi}$ that performs ${m}$ t-reads: $\textit{read}_{\phi}(X_{1})\cdots\textit{read}_{\phi}(X_{m})$ such that for all $i\in\{1,\ldots,m\}$, $\textit{read}_{\phi}(X_{i})\rightarrow v$.

Claim 8**.**

For all $i\in\mathbb{N}$, $\mathcal{M}$ has an execution of the form $\pi^{i-1}\cdot\rho^{i}\cdot\alpha^{i}$ where,

• •

$\pi^{i-1}$* is the complete step contention-free execution of slow-path read-only transaction $T_{\phi}$ that performs $(i-1)$ t-reads: $\textit{read}_{\phi}(X_{1})\cdots\textit{read}_{\phi}(X_{i-1})$,*

• •

$\rho^{i}$* is the t-complete step contention-free execution of a fast-path transaction $T_{i}$ that writes $nv_{i}\neq v_{i}$ to $X_{i}$ and commits,*

• •

$\alpha^{i}$* is the complete step contention-free execution fragment of $T_{\phi}$ that performs its $i^{th}$ t-read: $\textit{read}_{\phi}(X_{i})\rightarrow nv_{i}$.*

Proof.

$\mathcal{M}$ has an execution of the form $\rho^{i}\cdot\pi^{i-1}$. Since $\textit{Dset}(T_{k})\cap\textit{Dset}(T_{i})=\emptyset$ in $\rho^{i}\cdot\pi^{i-1}$, by Lemma 6, transactions $T_{\phi}$ and $T_{i}$ do not contend on any base object in execution $\rho^{i}\cdot\pi^{i-1}$. Moreover, since they each access a single t-object, fast-path transaction $T_{i}$ cannot incur a capacity abort. Thus, $\rho^{i}\cdot\pi^{i-1}$ is also an execution of $\mathcal{M}$.

By opacity, $\rho^{i}\cdot\pi^{i-1}\cdot\alpha^{i}$ (Figure 1(a)) is an execution of $\mathcal{M}$ in which the t-read of $X_{i}$ performed by $T_{\phi}$ must return $nv_{i}$. But $\rho^{i}\cdot\pi^{i-1}\cdot\alpha^{i}$ is indistinguishable to $T_{\phi}$ from $\pi^{i-1}\cdot\rho^{i}\cdot\alpha^{i}$. Thus, $\mathcal{M}$ has an execution of the form $\pi^{i-1}\cdot\rho^{i}\cdot\alpha^{i}$ (Figure 1(b)). ∎

For each $i\in\{2,\ldots,m\}$, $j\in\{1,2\}$ and $\ell\leq(i-1)$, we now define an execution of the form $\mathbb{E}_{j\ell}^{i}=\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}\cdot\alpha_{j}^{i}$ as follows:

• •

$\beta^{\ell}$ is the t-complete step contention-free execution fragment of a fast-path transaction $T_{\ell}$ that writes $nv_{\ell}\neq v$ to $X_{\ell}$ and commits

• •

$\alpha_{1}^{i}$ (and resp. $\alpha_{2}^{i}$) is the complete step contention-free execution fragment of $\textit{read}_{\phi}(X_{i})\rightarrow v$ (and resp. $\textit{read}_{\phi}(X_{i})\rightarrow A_{\phi}$).

Note that in the execution so defined above, we assume that each fast-path transactions $T_{i}$ and $T_{\ell}$;$\ell\leq(i-1)$ are executed by distinct processes.

Claim 9**.**

For all $i\in\{2,\ldots,m\}$ and $\ell\leq(i-1)$, $\mathcal{M}$ has an execution of the form $\mathbb{E}_{1\ell}^{i}$ or $\mathbb{E}_{2\ell}^{i}$.

Proof.

Note that by our assumption on capacity aborts, fast-path transactions $T_{i}$ and $T_{\ell}$ cannot incur capacity aborts in the defined execution.

For all $i\in\{2,\ldots,m\}$, $\pi^{i-1}$ is an execution of $\mathcal{M}$. By assumption of invisible reads, $T_{{\ell}}$ must be committed in $\pi^{i-1}\cdot\rho^{\ell}$ and $\mathcal{M}$ has an execution of the form $\pi^{i-1}\cdot\beta^{\ell}$. By the same reasoning, since $T_{i}$ and $T_{\ell}$ do not have conflicting data sets, $\mathcal{M}$ has an execution of the form $\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}$.

Since the configuration after $\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}$ is quiescent, $\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}$ extended with $\textit{read}_{\phi}(X_{i})$ must return a matching response. If $\textit{read}_{\phi}(X_{i})\rightarrow v_{i}$, then clearly $\mathbb{E}_{1}^{i}$ is an execution of $M$ with $T_{\phi},T_{i-1},T_{i}$ being a valid serialization of transactions. If $\textit{read}_{\phi}(X_{i})\rightarrow A_{\phi}$, the same serialization justifies an opaque execution.

Suppose by contradiction that there exists an execution of $\mathcal{M}$ such that $\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}$ is extended with the complete execution of $\textit{read}_{\phi}(X_{i})\rightarrow r$; $r\not\in\{A_{\phi},v\}$. The only plausible case to analyse is when $r=nv$. Since $\textit{read}_{\phi}(X_{i})$ returns the value of $X_{i}$ updated by $T_{i}$, the only possible serialization for transactions is $T_{\ell}$, $T_{i}$, $T_{\phi}$; but $\textit{read}_{\phi}(X_{\ell})$ performed by $T_{k}$ that returns the initial value $v$ is not legal in this serialization—contradiction. ∎

Claim 10**.**

For all $i\in\{2,\ldots,m\}$, $j\in\{1,2\}$ and $\ell\leq(i-1)$, slow-path transaction $T_{\phi}$ must access $(i-1)$ different base objects during the execution of $\textit{read}_{\phi}(X_{i})$ in the execution $\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}\cdot\alpha_{j}^{i}$.

Proof.

Consider the $(i-1)$ different executions: $\pi^{i-1}\cdot\beta^{1}\cdot\rho^{i}$, $\ldots$, $\pi^{i-1}\cdot\beta^{i-1}\cdot\rho^{i}$ (cf. Figure 1(c)). For all $\ell,\ell^{\prime}\leq(i-1)$;$\ell^{\prime}\neq\ell$, $\mathcal{M}$ has an execution of the form $\pi^{i-1}\cdot\beta^{\ell}\cdot\rho^{i}\cdot\beta^{\ell^{\prime}}$ in which fast-path transactions $T_{\ell}$ (executed by process $p_{\ell}$) and $T_{\ell^{\prime}}$ (executed by process $p_{\ell^{\prime}}$) access mutually disjoint data sets. By invisible reads and Lemma 6, the pairs of transactions $T_{\ell^{\prime}}$, $T_{i}$ and $T_{\ell^{\prime}}$, $T_{\ell}$ do not contend on any base object in this execution. This implies that $\pi^{i-1}\cdot\beta^{\ell}\cdot\beta^{\ell^{\prime}}\cdot\rho^{i}$ is an execution of $\mathcal{M}$ in which transactions $T_{\ell}$ and $T_{\ell^{\prime}}$ each apply nontrivial primitives to mutually disjoint sets of base objects in the execution fragments $\beta^{\ell}$ and $\beta^{\ell^{\prime}}$ respectively.

This implies that for any $j\in\{1,2\}$, $\ell\leq(i-1)$, the configuration $C^{i}$ after $E^{i}$ differs from the configurations after $\mathbb{E}_{j\ell}^{i}$ only in the states of the base objects that are accessed in the fragment $\beta^{\ell}$. Consequently, slow-path transaction $T_{\phi}$ must access at least $i-1$ different base objects in the execution fragment $\pi_{j}^{i}$ to distinguish configuration $C^{i}$ from the configurations that result after the $(i-1)$ different executions $\pi^{i-1}\cdot\beta^{1}\cdot\rho^{i}$, $\ldots$, $\pi^{i-1}\cdot\beta^{i-1}\cdot\rho^{i}$ respectively. ∎

Thus, for all $i\in\{2,\ldots,m\}$, slow-path transaction $T_{\phi}$ must perform at least $i-1$ steps while executing the $i^{th}$ t-read in the execution fragment $\pi_{j}^{i}$. Inductively, this gives the $\sum\limits_{i=1}^{m-1}i=\frac{m(m-1)}{2}$ step complexity for $T_{\phi}$ thus completing the proof. ∎