My programming-languages view of TM: Research and Conjectures

1. My programming-languages view of TM: Research and Conjectures Dan Grossman University of Washington June 2008

2. Who am I • Programming-languages researcher • Formal semantics, type systems, compilers, etc. • UW 2003-present, Cornell Ph.D., Rice undergrad • Formerly: Cyclone, a type-safe C • Now portable C-level code • TM interest from frustration that data-race prevention was about, “getting to the starting line” • Checking atomicity better • Declaring atomicity even better Dan Grossman, University of Washington

3. Broad summary In the next 14 minutes: • Advertisement for past/present TM work • Motivation for TM in HLLs • Semantics, weak vs. strong • PL design (feature interaction) • Language implementation, optimizations • Provocative(?) conjectures for further discussion Dan Grossman, University of Washington

4. Credit Semantics: Katherine Moore Uniprocessor: Michael Ringenburg, Aaron Kimball Optimizations: Steven Balensiefer, Ben Hindman Implementing multithreaded transactions: Aaron Kimball Memory-model issues: Jeremy Manson, Bill Pugh Weak vs. Strong STM: Tatiana Shpeisman, Vijay Menon, Ali-Reza Adl-Tabatabai, Richard Hudson, Bratin Saha Implementing multithreaded transactions: Tim Harris wasp.cs.washington.edu Dan Grossman, University of Washington

5. Please read High-Level Small-Step Operational Semantics for Transactions [POPL08]Katherine F. Moore, Dan Grossman The Transactional Memory / Garbage Collection Analogy [OOPSLA07]  Dan Grossman Software Transactions Meet First-Class Continuations[SCHEME07]  Aaron Kimball, Dan Grossman Enforcing Isolation and Ordering in STM [PLDI07] Tatiana Shpeisman, Vijay Menon, Ali-Reza Adl-Tabatabai, Steve Balensiefer, Dan Grossman, Richard Hudson, Katherine F. Moore, Bratin Saha Atomicity via Source-to-Source Translation [MSPC06] Benjamin Hindman and Dan Grossman What Do High-Level Memory Models Mean for Transactions? [MSPC06] Dan Grossman, Jeremy Manson, William Pugh AtomCaml: First-Class Atomicity via Rollback [ICFP05] Michael F. Ringenburg, Dan Grossman Dan Grossman, University of Washington

6. Motivation So atomic{ … }“sure feels better than locks” But the crisp software-engineering reasons I’ve seen are all (great) examples • Account transfer from Flanagan et al. • See also Java’s StringBuffer.append • Double-ended queue from Herlihy • … Dan Grossman, University of Washington

7. Motivation But what is the essence of the benefit? Transactional Memory (TM) is to shared-memory concurrency as Garbage Collection (GC) is to memory management Dan Grossman, University of Washington

8. Motivation (see the essay) Dan Grossman, University of Washington

9. Motivation GC: established technology; widely accepted benefits • Even though it can perform arbitrarily badly in theory • Even though you can’t always ignore how it works (at a high-level) • Even though an active research area after 40+ years Dan Grossman, University of Washington

10. Semantics The potential behavior when nontransactional code bypasses TM mechanisms is worse than with locks initially b=0, x=0, y=0 atomic { if(b) ++x; else ++y; } r = x; s = y; assert(r+s<2); atomic { b = 1; } (Note: Other examples don’t even have data races in the corresponding lock-based code.) Dan Grossman, University of Washington

11. Semantics In a type-safe high-level language: • We must know we found all the surprises • And define legal behaviors • Even “bad” code cannot violate security/abstraction • Best intellectual tool we have is formal semantics • My work: small-step operational a;H;e1|| … ||en a’;H’;e1’|| … ||en’ Dan Grossman, University of Washington

12. Semantics • Different notions of isolation by changing • Equivalence proofs under source-code assumptions formalized via type-and-effect systems • Proofs mean no more surprises (in the model) • Structure of proofs reveal the key invariants a;H;e1|| … ||en a’;H’;e1’|| … ||en’ strong-undo strong weak-1-lock weak-undo Dan Grossman, University of Washington

13. Semantics There is much left to do beyond weak vs. strong • Open nesting (in terms of ADTs) • Relaxed memory-consistency models • … Dan Grossman, University of Washington

14. Language design Real languages need precise semantics for all feature interactions. For example: • Native Calls [ICFP05] • Exceptions [ICFP05, SCHEME07] • First-class continuations [SCHEME07] • Thread-creation [POPL08] • Java-style class-loading [MSPC06] Dan Grossman, University of Washington

15. Implementation If a TM application is (currently) running on one core, use thread-scheduling to ensure atomicity • Memory-access overhead Also: initialization writes need not be logged • Strong isolation naturally Dan Grossman, University of Washington

16. Implementation Strong isolation on multicore: remove barriers with compiler/runtime optimization Novel: static analysis for not-accessed-in-transaction • Currently whole-program (but scalable) Thread local Not accessed in transaction Immutable Dan Grossman, University of Washington

17. Implementation • Most implementations (hw or sw) assume code inside a transaction is single-threaded • But isolation and parallelism are orthogonal • Amdahl’s Law will strike with manycore • Ongoing work: Multithreaded transactions • Key: Nested transactions for nested isolation • Key: correct logging without sacrificing parallelism Dan Grossman, University of Washington

18. Discussion starters [Happy to be convinced otherwise, but I conjecture…] • Like GC, don’t need hardware support (but it’s nice) • Like GC, widespread adoption will take lots of time • Like GC, we rarely need “back doors” • A high-level language with TM wouldn’t directly use HTM even if available • The PL community has ignored memory consistency models for too long and will soon regret it • What ordering guarantees do transactions imply? Dan Grossman, University of Washington