Rich Transactions on Reasonable Hardware

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTSASSACHUSETTS, A, AMHERST • MHERST • Department of Computer Science Department of Computer Science

Rich Transactions onReasonable Hardware

J. Eliot B. Moss

Univ. of Massachusetts, Amherst

[email protected]


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


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


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)


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, ...


Semantics of Nesting Actions (2) No additional syntax, richer semantics Hardware support needed:

Tag lines with txn id (SMTs need anyway) Multiple copies of 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)


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


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


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


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


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


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 ...


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


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


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


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

Documents

Rich Transactions on Reasonable Hardware