Supporting existing code in a transactional memory system

1. Supporting existing code in a transactional memory system • Nate Nystrom • Mukund Raghavachari • IBM • TRAMP • 5 Mar 2007

2. Transactional memory • Want to use TM for many software engineering reasons: • simple concurrent programming model • composability • avoids common errors: deadlock, priority inversion … • But, how does it interact with existing code? atomic { if (a.balance > n) { a.balance -= n; b.balance += n; } }

3. Interacting with existing code • Existing code may not fit into transactional model • Some operations cannot be undone or redone • e.g., I/O • but maybe encapsulated by operations that can • Disparate memory models • database transactions • explicit synchronization • Consistency between TM-managed state and other state • Access to existing code can restrict TM implementation • Performance implications • Working to address these issues in the DALI Project

4. Open operations and compensations • Open operations • Execute without locking, logging • Programmer again responsible for concurrency control  • Compensations [Garcia-Molina 89] [Weimer, Necula 04] • Record closure to be invoke when enclosing transaction rolls back • Need to compensate at appropriate level of abstraction • can be application, rather than library specific • Implemented on top of AtomJava [Grossman, Hindman 05] open { c.executeUpdate(“INSERT INTO orders VALUES (“ + id ... + ”)”); } undo { c.executeUpdate(“DELETE FROM orders WHERE oid = “ + id + ”); }

5. Expanders • Use expanders [Warth, Stanojevic, Millstein 06] to simplify adaptation of non-transactional code • Methods dispatched through expanders, which specify compensation code expander ListEx of List { void add(Object o) { open { inner.add(o); } undo { inner.remove(o); } } ... } use ListEx; List l = ...; l.add(x); // -> ListEx.add(x) // -> List.add(x)

6. Transaction event listeners • Register handlers to be invoked at begin, commit, rollback expander PSEx of PrintStream { PSListener l = new PSListener(inner); void print(String s) { l.sb.append(s); } } class PSListener implements TransactionListener { StringBuffer sb; PrintStream out; void commit(Transaction t) { // flush buffer at outermost commit if (t.parent == null) out.print(sb.toString()); } }

7. Integration of software and database transactions • Transactions can access both transient and persistent state • Use transaction event listeners to: • Problems: multiple databases • JDBC-specific problems: deadlock, auto-commit

8. Conclusions • Integrating existing code into TM system presents several challenges • Compensations, expanders, transaction listeners are abstractions that make this integration easier • Implemented database transactions seamlessly • Hard issues: • Interaction of explicit synchronization and TM • Consistency of TM-managed state and other state • Strong consistency guarantees with open transactions • Performance