The road map of this work is as follows. Chapter 1 presented an overview of TM, including its advantages and disadvantages compared to other parallel programming concepts.
Chapter 2 begins by presenting conflict detection, an active area of research in TM optimiza- tions. We then present new methods for optimizing TMs using invalidation, which in some cases are more efficient than the prior state-of-the-art systems. Chapter 3 follows by formalizing the STM implementation of Chapter 2. In Chapter 2 and prove that a history that is accepted by a full invalidation automaton is both conflict and view serializable.
Chapter 4 and 5 focus on the importance of an invalidation-based STM for both efficiency and simplicity. Chapter 4 shows that an invalidation-based STM can outperform a validation-based STM by upwards of 100× for systems that must respect user-defined priority-based transactions. Chapter 5 demonstrates that in order for transactions and locks to work together in the same program, some form of invalidation may be necessary. Furthermore, Chapter 5 demonstrates that if a TM uses invalidation, it may reduce the system’s overall complexity when making that TM lock-aware.
Chapter 6 presents a brief conclusion of this work. We discuss the practical performance of an efficient implementation of full invalidation, the theory of full invalidation, priority-based transactions in a full invalidation TM, and lock-aware TM using full invalidation.
Optimizations: Transactional Contention and Memory-Intensive Transactions
Many TMs use an optimistic concurrency model in which transactional operations are exe- cuted concurrently and the operations that violate the TM’s supported serializability [50, 67] are un- done. Some degree of computational overhead is incurred when TMs provide an optimistic concur- rency model where the transaction commit order is serializable, and the transactions themselves are atomic and isolated. Furthermore, some researchers argue that this incurred computational over- head is too great for TM to be practical [12]. To address these concerns, researchers have found in- novative ways to reduce the overhead of TMs by optimizing conflict detection [17, 19, 59, 74, 86, 84]. Conflict detection, the process of determining if transactions can commit [84], is usually implemented as a conservative overestimation of some form of serializability [68]. A transaction can commit as long as its commit preserves some precise definition of serializability with regard to the total transaction commit order. Serializability is usually preserved by disallowing some number of transactional conflicts from existing between committed transactions. A transactional conflict is loosely defined as the non-null intersection between one active transaction’s write elements and another active transaction’s read and write elements [50, 60, 74]. While significant work has been done in the area of conflict detection and resolution, nearly all TMs perform commit-time validation, a strategy where a single transaction’s read elements, and sometimes its write elements, are checked for consistency during a transaction’s commit phase.
Commit-time validation typically uses version numbers associated with memory to track
elements (also known as read and write sets) are compared against the version numbers of the same memory stored, and shared, globally. If a version mismatch is found, the validating transaction is aborted because a previously committed transaction has updated the same memory. If no mismatch is found the transaction is consistent and can be committed. While commit-time validation is efficient for workloads that exhibit little contention, it limits transaction throughput, the number of transactions that commit per second, for contending workloads. This is because commit-time validation does not determine how many in-flight transactions will be aborted due to a transaction’s commit.
In this chapter we analyze the differences between commit-time validation and commit-time invalidation for transactions that access many memory elements and for workloads where notable contention exists between transactions. Commit-time invalidation is an implementation of the full invalidation, where full invalidation is a specification for conflict detection which is defined precisely in Chapter 3. In general, commit-time invalidation finds transactional conflicts by comparing the memory of a committing transaction against the memory of in-flight transactions. Commit-time invalidation differs from commit-time validation in that all of a committing transaction’s conflicts with in-flight transactions are found and resolved before the transaction commits. Conflicts are sent to the contention manager (CM), the process that decides which transactions make forward progress [36, 49, 79], for resolution. The CM resolves conflicts by either (1) aborting all conflict- ing in-flight transactions, (2) aborting the committing transaction, or (3) stalling the committing transaction until the conflicting in-flight transactions have committed or aborted [84]. Through this mechanism, commit-time invalidation can notably increase transaction throughput when compared to commit-time validation for contending workloads.
Although invalidation is not a new idea [22, 26, 39, 49, 81, 84, 83], to the best of our knowledge, no prior work has implemented an efficient TM (one that is competitive with the state-of-the-art) using only invalidation. Inefficiencies found in prior attempts have steered TM research toward validation. In this chapter we demonstrate that a TM which only uses commit-time invalidation can be implemented efficiently. In doing so, this chapter iterates through the following contributions:
(1) Full commit-time invalidation can increase transaction throughput by supplying a CM with more information than is possible using commit-time validation, allowing the CM to make informed and efficient decisions.
(2) Optimized commit-time invalidation has a slower asymptotic operational growth rate than commit-time validation with regard to the memory elements accessed within a transac- tion. This means that as the number of memory elements within a transaction increase, commit-time validation requires proportionally more operations to perform than commit- time invalidation.
(3) Commit-time invalidation requires zero operations to identify conflicts in dynamically de-
tected read-only transactions and ensures opacity1 [37] for any transaction in O(N ) time,
where N is the number of elements in the transaction’s read set, an improvement over
incremental validation’s O(N2) time.
(4) Our efficient commit-time invalidating STM, InvalSTM, is over 3× faster than TL2 [17], a state-of-the-art validating STM, for certain contending workloads. We further show that our earlier STM, DracoSTM, outperforms RSTM for memory-intensive transactions.