Transactional Programmability and Performance

Transactional memory is a promising technique for multithreaded synchronization and concurrency which has attracted much interest in recent years. Compared to locks, transactions can offer increased concurrency, composability, and deadlock freedom; yet their speculative nature introduces problems not seen in lock-based code, and these have limited the adoption of transactions as a serious alternative to locks. Specifically, it is not clear how transactions can contain side-effecting actions like I/O, nor how they can scale to arbitrary footprints and durations while retaining acceptable performance and a consistent and desirable programming semantic. I believe that addressing problems like these is of first importance to programmers considering using transactions. In this work, I seek to extend the programmability of transactions by exploring and addressing these problems. I begin by exploring the domain of hardware support for software transactional memory. I first show how a general-purpose user-mode memory protection system can be used to provide strong isolation to software transactional memory systems with little hardware and minimal performance overhead. Then I show how to augment this strongly atomic software transactional memory system with a 'best-effort' hardware transactional memory system to yield a hybrid transactional memory system, the UFO Hybrid, in which high-performance hardware transactions can run concurrently with large, long, nested, or side-effecting software transactions. Compared to previous hybrid transactional memory proposals, my system offers a strongly atomic programming model for both its hardware and its software transactions, low-overhead conflict detection between its hardware and software transactions, and high HTM performance even in the presence of potentially-conflicting software transactions. I show through experimental analysis that the UFO Hybrid performs at least as well as competing hybrid transactional memory systems, and significantly outperforms them when some transactions are forced to fail over to software. I also provide an analysis of I/O in lock-based critical sections in large multithreaded workloads, with observations on how this I/O could be performed in transactional code. In this analysis, I find that no one of the previously proposed techniques is by itself sufficient for handling side-effects without sacrificing performance. However, I conclude that the majority of transactional I/O is likely to be compensatable, and that causing transactions performing I/O to 'go nonspeculative' can be a reasonable choice for uncompensated I/O, provided that it does not delay non-side effecting transactions