In this chapter, we introduce different aspects of TM-based programming. First we motivate the transaction abstraction by presenting it as a concurrent programming language tool and by depicting its advantages over using locks. Then, we focus on the programming aspect of TM-based programming. In this part, we describe the semantics of the transaction abstraction provided by a TM (transaction semantics) as well as the semantics of the language construct providing the transaction abstraction (transaction block semantics). For transaction semantics, we describe the proposed correctness and progress guarantees a transaction should ensure. Although there is no agreed guarantee for transaction semantics, later in the chapter, while discussing TM implementations, we observe that in practice the widely accepted correctness guarantee is opacity, i.e., the execution of transactions is such that an equivalent sequential order of transactions can be found and no transaction executes based on inconsistent state at any time. Although opacity is a weak isolation guarantee, which is the not the ideal transaction semantics for correctness (strong isolation would be the ideal semantics), the overhead of ensuring a stronger guarantee is the major reason for the common use of opacity. For progress, the current trends indicate two major dominating guarantees: blocking (lock-based TMs) and obstruction-free. Blocking TMs are common in practice due to their efficiency, while TMs targeting non-blocking progress prefer obstruction-freedom due to simplicity of its design.
Although practically the semantics used for transactions is more or less fixed, different semantics for transactions should still be evaluated to decide which one fits the best for application execution. Moreover, TM design is a complicated task and ensuring the desired semantics is generally a hard task. In order to overcome these issues designers require tools that they could use to evaluate semantics of the transaction abstraction they provide. In Chapter 4 we address this issue and propose a tool, TMunit, that is tailored for this purpose.
Although transaction semantics is the base of the semantics of a transactional language construct (transaction block), the interaction of such language construct with other lan- guage constructs and features is mainly the subject of transactional block semantics. In this chapter, we also present the major problems a transaction block would have in interacting other language constructs and features and analyze proposed solutions for different classes of such incompatible language constructs, namely, memory allocation code, synchronization actions, external code and exceptions. Although solutions exist for each separate construct or feature, very few studies integrate them together within a language. Later in Chapter5, we provide a language extension specification for transaction blocks, taking both transac-
tion and transaction block semantics into account and proposing an integrated solution for different classes of incompatible constructs. We complete this specification by depicting how the specification can be implemented in Chapter 6using our second tool TMJava.
Among the different classes of incompatible constructs with which a transaction block should interact, a general solution that applies to all but exceptions is the use of irrevoca- bility, i.e., running a transaction such that it can not be aborted by others. For exceptions, irrevocability is not an option because they are not part of normal program execution and it is not acceptable to run transaction using irrevocability (which introduces a significant overhead) just because a transaction block can potentially raise an exception. Hence, in this thesis, we have analyzed existing work to support exceptions in detail and provided the programmer (through the language extension we propose in Chapter 5) all the solutions that are required to support exceptions within transaction blocks. We have also figured out that multi-threaded applications have further exception related requirements compared to single-threaded ones. Exceptions in multi-threaded applications may need to be handled in cooperation by multiple threads and, in general, there is no support for such functionality in popular programming languages. This advanced functionality is treated in Chapter 7 and is embodied within an augmented transaction block construct (atomic box) presented as part of our language extension.
At the end of the chapter, we focus on TM implementations and their performance. Using example TM implementations, we describe key design mechanisms that make dif- ferent implementations efficient. However, generally no TM implementation to date can yet perform better than any other for all workloads. Hence, it is important to identify the workloads where different design choices perform poorly. While such a study have barely been done, in Chapter4we evaluate different TMs under a variety of workloads to perform such identification. Additionally, apart from observing TM implementations through exper- iments, we analyze STM algorithms and identify some design decisions that allow us to classify different STM implementations. We present this classification in the next chapter.
Qualitative Classification of STM
Designs
3.1
Introduction
STM design incorporates many design decisions, resulting in a large STM design space (see Appendix A). Finding a winning combination of design decisions is not an easy task and, hence, the quest for such a combination is still an active and hot research topic. Such research requires the comparison of many design alternatives in different circumstances. In this chapter, we aim at providing a classification of STM designs, grouping several design decisions together, in order to narrow down the possible design alternatives to be compared. A quantitative comparison of designs is always possible, but taking into account the diversity of mechanisms proposed for STMs, the implementation effort to compare multitude of combinations may not be practical. Hence, a good solution is first to classify designs qualitatively and then compare representatives of each class. In this chapter, we introduce our effort in providing such a qualitative classification.
In general, it is easier to compare designs using metrics, since metrics allow to reason about the quality of the design in terms of what the metric represents (e.g., speed, efficiency, energy consumption etc.). Most studies in STMs measure the throughput metric to evaluate STM designs (see Section2.6). This metric is valuable as it gives an idea of how efficient an STM is, but, per se, it does not always provide a good understanding about why an STM design is efficient. One STM may be efficient either because it aborts very few transactions or because it retries transactions very rapidly. Hence, in order to have a better understanding of the efficiency of STMs we need metrics that are complementary to throughput. In this
chapter, we introduce such a novel metric, commit-abort ratio (which is associated to a novel notion called input acceptance) and classify major STM designs based on this metric. The chapter is organized as follows. In Section 3.2 we start by illustrating that most STMs abort in cases where application correctness would have been ensured without abort- ing (unnecessary aborts). We then introduce the commit-abort ratio and the associated notion input acceptance in Sections 3.3 and 3.4 respectively and explain how they are related to unnecessary aborts. In Section 3.5 we explain how we classify STM designs according to the unnecessary aborts they generate and then present the different design classes in Sections 3.5.1through 3.5.5. We explain how the presented classes are related in Section 3.6 and conclude the chapter with Section3.7.