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

2. Dan Grossman, University of Washington2 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

3. June 2008Dan Grossman, University of Washington3 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

4. June 2008Dan Grossman, University of Washington4 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

5. June 2008Dan Grossman, University of Washington5 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

6. June 2008Dan Grossman, University of Washington6 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 –…

7. June 2008Dan Grossman, University of Washington7 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

8. June 2008Dan Grossman, University of Washington8 Motivation (see the essay) memory managementconcurrency correctnessdangling pointersraces performancespace exhaustiondeadlock automationgarbage collectiontransactional memory key approximationreachabilitymemory conflicts manual circumventionweak pointersopen nesting complete avoidanceobject poolinglock library uncontrollable approx.conservative collectionfalse memory conflicts eager approachreference-countingupdate-in-place lazy approachtracingupdate-on-commit external dataI/O of pointersI/O in transactions forward progressreal-timeobstruction-free static optimizationsliveness analysisescape analysis

9. June 2008Dan Grossman, University of Washington9 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

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

11. June 2008Dan Grossman, University of Washington11 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’

12. June 2008Dan Grossman, University of Washington12 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’ strongweak-1-lockweak-undo strong-undo

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

14. June 2008Dan Grossman, University of Washington14 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]

15. June 2008Dan Grossman, University of Washington15 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 not in atomicin atomic readnone writenonelog (2 more writes)

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

17. June 2008Dan Grossman, University of Washington17 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

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