1. April 8, 2005Transactions Everywhere 1 Bradley C. Kuszmaul Charles E. Leiserson MIT CSAIL Joint research with Scott Ananian, Krste Asanović, Michael A. Bender, Martin Farach- Colton, Sean Lie, Gideon Stupp, and Jim Sukha. This research was supported in part by NSF Grant ACI- 0324974 “Transactions Everywhere,” by NSF Grant CNS-0305606, and by the Singapore-MIT Alliance.

2. April 8, 2005Transactions Everywhere 2 Transaction Bounds Definition. A transactional-memory system is bounded in duration if there exists a finite upper bound T on the time any xaction can execute. Definition. A transactional-memory system is bounded in footprint if there exists a finite upper bound B on the number of locations any xaction can access. Definition. A transactional-memory system is unbounded if it supports xactions of arbitrary duration and footprint.

3. April 8, 2005Transactions Everywhere 3 We have developed a hardware mechanism that is fast for small xactions and correct for large xactions. We automatically converted the lock-based Linux 2.4.19 kernel to use xactions. 100% Xaction Footprint (64-Byte Cache Lines) 10% 0.1% 0.001% make dbench % Xactions That Are Bigger The largest xaction accesses over 8000 cache lines. 99.9% of xactions fit in 54 cache lines. Distribution of Footprint 1% 0.0001% 0.01% 11010010008144 0.00001%

4. April 8, 2005Transactions Everywhere 4 Transactional Linguistics We are experimenting with two languages: Transactional Cilk (XCilk) Transactional Java (XJava) Philosophy: Start with a correct program, and then speed it up; not start with a fast, incorrect program, and then add critical regions. Preliminary conclusions: Need unbounded xactions. The nonpreemptive scheduling semantics of yore provide a good model. Nonatomicity composes; atomicity does not.

5. April 8, 2005Transactions Everywhere 5 Fallacy of Bounded Xactions Our Thesis Only unbounded xactions can serve as a general tool for building large-scale software systems. Our Thesis Only unbounded xactions can serve as a general tool for building large-scale software systems. Q. What should the programmer or compiler do with a xaction that requires longer duration than T or larger footprint than B? A. We don’t know. But, unless a good answer can be found (and we’re doubtful), bounded xactions seem to be fatally flawed. *Okay, but in practice, nothing is unbounded. For example, is the size of physical memory a big enough bound on footprint? Sure would make the hardware easier! *

6. April 8, 2005Transactions Everywhere 6 Toward Transactions Everywhere Guaranteeing forward progress should not be left up to the application. The x-system (HW, OS, compiler) must solve it. Unfortunately, race detection is algorithmically harder with xactions than with locks. The x-mechanism must provide a semantic loophole for logging, debugging, and I/O. Semantics of x-consistency may actually speed up hardware. Stronger concurrency control in HW? E.g., read-only xactions always complete. How visible is the x-state, and how should the OS deal with it if it is invisible?