Supporting existing code in a

transactional memory system

Nate NystromMukund Raghavachari

IBM

TRAMP5 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; } }

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 + ”);}

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)

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()); }}

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

At begin: Create a savepointAt rollback: Rollback to savepoint

Rollback software transactions

At nested commit:

Discard savepoint

At outermost commit:

Commit database transactionIf successful commit S/W txn

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