Transactions Everywhere Bradley C Kuszmaul Charles E Leiserson

Transactions Everywhere 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. April 8, 2005 Transactions Everywhere

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. April 8, 2005 Transactions Everywhere

Distribution of Footprint • 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. % Xactions That Are Bigger 100% The largest make dbench 10% xaction accesses over 8000 cache lines. 1% 0. 01% 99. 9% of 0. 001% xactions fit in 54 cache lines. 0. 0001% 0. 00001% 1 10 1000 8144 Xaction Footprint (64 -Byte Cache Lines) April 8, 2005 Transactions Everywhere 3

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. April 8, 2005 Transactions Everywhere

Fallacy of Bounded Xactions 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. Our Thesis Only unbounded xactions can serve as a general tool for building large-scale software systems. * *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! April 8, 2005 Transactions Everywhere

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? April 8, 2005 Transactions Everywhere