Lightweight, robust adaptivity for software transactional memory
Proceedings of the twenty-second annual ACM symposium on Parallelism in algorithms and architectures
On transactional scheduling in distributed transactional memory ystems
SSS'10 Proceedings of the 12th international conference on Stabilization, safety, and security of distributed systems
Hardware transactional memory with software-defined conflicts
ACM Transactions on Architecture and Code Optimization (TACO) - HIPEAC Papers
A transactional memory with automatic performance tuning
ACM Transactions on Architecture and Code Optimization (TACO) - HIPEAC Papers
A composable mixed mode concurrency control semantics for transactional programs
ICFEM'12 Proceedings of the 14th international conference on Formal Engineering Methods: formal methods and software engineering
Tightfit: adaptive parallelization with foresight
Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering
| Hi-index | 0.01 |
In this paper we investigate feedback-directed dynamic selection between different implementations of atomic blocks. We initially execute atomic blocks using STM with optimistic concurrency control. At runtime, we identify “hot” variables that cause large numbers of transactions to abort. For these variables we selectively switch to using pessimistic concurrency control, in the hope of deferring transactions until they will be able to run to completion. This trades off a reduction in single-threaded speed (since pessimistic concurrency control is not as streamlined as our optimistic implementation), against a reduced amount of wasted work in aborted transactions. We describe our implementation in the Haskell programming language, and examine its performance with a range of micro-benchmarks and larger programs. We show that our technique is effective at reducing the amount of wasted work, but that for current workloads there is often not enough wasted work for an overall improvement to be possible. As we demonstrate, our technique is not appropriate for some workloads: the extra work introduced by lock-induced deadlock is greater than the wasted work saved from aborted transactions. For other workloads, we show that using mutual exclusion locks for “hot” variables could be preferable to multi-reader locks because mutual exclusion avoids deadlocks caused by concurrent attempts to upgrade to write access.