Architectures for transactional memory

Engineers have successfully worked for decades to improve single thread CPU performance, but we have now reached a peak in what a single thread can do. Average programmers are now facing the eventuality that their code must be parallel to take advantage of the performance potential of multi-core chips. Unfortunately, writing parallel programs is hard because synchronizing accesses to shared state is complex and error-prone—many techniques have been tried, but achieving performance and correctness simultaneously still requires expert programmers, and the method of choice is decades old (locks). Transactional Memory (TM) is a relatively new programming paradigm promising an easier road to correctness and performance using atomic code regions. These regions may then be speculatively executed in parallel, potentially providing performance gains. This dissertation focuses on architecting and evaluating hardware TM systems. We begin by briefly arguing that TM should be implemented in hardware, since proposed software solutions suffer from poor performance. We then study qualitatively and quantitatively the large design space for hardware TM as defined by primary options such as version management and conflict detection, and vary the secondary options such as the structure of the memory hierarchy, the instructions per cycle, and the configuration of the interconnect. Orthogonally, we determine the semantics and interfaces needed by any hardware TM system to support rich software functionality in modern operating systems and programming languages. Finally, we extend hardware support for transactional execution to create a multi-core architecture that provides cache coherence and memory consistency at the granularity of atomic transactions. We conclude that programs written with transactional memory can achieve comparable to and often superior performance than the same programs written with traditional synchronization methods. Furthermore, a transactional architecture implementing lazy versioning and optimistic conflict detection is the preferred method of implementing TM in hardware due to its simplicity and good performance across a wide range of contention scenarios. Also, to support rich semantics, you need four mechanisms: two-phase transaction commit, software handlers, nested transactions, and non-transactional loads and stores. Finally, a continuously transactional architecture called Transactional Coherence and Consistency (TCC) maintains performance benefits while simplifying the hardware implementation of TM.