Rich Transactions on Reasonable Hardware

1. Rich Transactions onReasonable Hardware J. Eliot B. Moss Univ. of Massachusetts, Amherst moss@cs.umass.edu

2. Language/Virtual Machine Challenges • Common uses of TM simple for programmer • Semantics simple, clean, useable • Realize potential programming benefits • Advanced uses possible and clean • Overcome hardware limitations • Size of transactions • Semantics of what’s built in

3. The Simplest Case • Setting: Java (can explore other platforms) • Credit to Harris and Fraser for simple form: atomic {statements} Executes statements: • Either entirely or not at all • Repeated until succeeds: exactly-once effect • A single state transition (as seen by others) • Provides a simple model: ACI of ACID

4. Mapping Simple Form to Hardware • Transaction = read & write set of cache lines • Conflict if write line touched by other txn • Abort = drop set of records, buffered writes • Commit = drop records, install writes • Issue: Txns with large sets • Need graceful overflow to memory • Perhaps even to virtual memory (disk)

5. Semantics of Nesting Actions • Harris & Fraser: Aggregate into one big set • This one big txn commits only at top level • Closed Nesting: • Sub-txn can abort without top aborting • Sub-txn commits “into” top’s sets • Retry high-conflict part w/o aborting all • Good for libraries, composing modules • Allows alternate strategies, optional parts, ... • m-of-n replica commit, ...

6. Semantics of Nesting Actions (2) • No additional syntax, richer semantics • Hardware support needed: • Tag lines with txn id (SMTs need anyway) • Multiple copiesof same line; different ids • Txn id analogous to address space ID • Can get by with a handful of bits • Add parent/child txn table • More complex txn conflict detect logic • Txn relationships can be cached (like TLB)

7. Predicated (Conditional) Actions • Harris and Fraser construct: atomic (predicate) { stmts } stmts executed only when predicate is true • Evaluate predicate (as part of an action) • If true, continue to evaluate stmts • predicate and stmts part of same action • If false, “wait until predicate is true” • In hardware, set to lowest priority, then ... • Wait until read/write set conflict and retry

8. Predicated Actions: Hardware Need • “Low priority” notion, so waiter aborted • Giving up after a while, controls on how long • Possibly maintaining state for waiting thread • No explicit notify: conflict is the indicator • If predicate tends to be cheap, just retry • Kicking up to s/w for more explicit handling

9. Beyond Closed Nesting • Closed nesting only builds largers sets • Consider modifying a cache or table • New/deleted entries touched: ok, since want to block access to modifications • Things along path in data structure: creates often undesirable conflicts • Need: Distinguish physical data structure from its logical contents

10. Beyond Closed Nesting: Open Nesting • Open nesting: • Open nested action truly commits changes • Leaves explicit access control information • Access control managed by software • Abort of enclosing txn requires undo • Retry of enclosing txn requires redo

11. Open Nesting Syntax/Design • Possible syntax: open atomic {stmts} undo { u } redo { r } • Implementation strategy: • Language run-time builds undo/redo lists • When needed, they are run as txns • Need access to txn ids, conflict tests, etc. • Transactions become explicit, can be named and manipulated

12. Some Applications of Open Nesting • Shared table structures (already noted) • May help support GC: • Open nested commit updates (some) data held by enclosing atomic blocks: supports GC work done by executing thread • Admittedly idea still rough ... • GC from other threads may need “reflective” ability to see/update transactional data of application threads ...

13. Other Desired Features • atend actions: happen at end of top-level • May help with issue of I/O • Connection to OS supported durability • Specially designated pages + commit call • Lock coupling: “release locks” on parts of data structures walked but not needed E.g.: searching list linearly to remove item

14. Other Desired Features (2) • Checkpointing and rollback to checkpoints • Concurrency: spawning parallel sub-txns • Transaction per loop iteration • Control on ordering relationships • H/W:OS desire: cheap thread spawning • Implication: multiple threads, each working within the same transaction hierarchy • Again, explicit txn ids make this easier

15. Non-Normal Outcomes • Harris and Fraser exception semantics: • Throwing is a transaction success • Usual Java semantics • Claim: More useful to undo visible effects • Abort writes to previously existing objects • Retain objects created in failing txn • Allows return of reason for failure • Example: Denied credit

16. Non-Normal Outcomes (2) • Example syntax: fail with new Exc(...); • Challenge: keeping some state, tossing rest • May be able to implement this with combination of open nesting and run-time system support: • In open nested action, create copy of newly allocated reachable objects and commit the open nested txn