Nested Transactional Memory: Model and Preliminary Sketches

1
Nested Transactional Memory Model and
Preliminary Sketches

• J. Eliot B. Moss and Antony L. Hosking
• Presented by Michelle J. Moravan

2
Outline

• Current Transactional Memory Model
• Why nesting? Compositionality.
• Linear Nesting
• Closed Transaction Semantics
• Open Transaction Semantics
• Non-Linear Nesting
• Summary Conclusions

3
Current TM Model

• One thread per processor
• At a time
• One live transaction per thread
• Live transaction begun but not committed or
  aborted

4
Illustration
atomic tmp a a b b tmp
atomic a init() foo(c) atomic b
5
Versions Conflicts

• Versions
• Global state
• State per live transaction
• Granularity?
• Conflicts
• One writer or multiple readers
• Granularity?
• Transaction thread processor

6
Compositionality

• Should define and allow nesting
• Begin a new transaction within a live transaction
• Why?

7
Motivating Example
User Code
Library Code
atomic a init() foo(c) atomic b
init() atomic d return d
8
Current HW Solution

• Current HTMs subsume
• Treat instructions of inner transactions as
  though they were explicitly part of the top-level
  transaction
• Top-level transaction one thats not nested in
  any other transaction

9
Linear Nesting
atomic //x1 atomic //x2 atomic //x3
atomic //x4

• Multiple transactions at same level
• Only one transaction per level live
• Only one transaction running
• Can commit, abort, and do memory operations
• Must be the deepest live transaction

10
Terminology Time Flow
top-level
ancestor
x1
older
parent
child
x4
x2
siblings
younger
descendant
x3
11
Versions Conflicts

• Versions
• Still have global version
• Now additionally one version per live transaction
  per tree
• Conflicts
• Ancestors descendants dont conflict
• Only conflict with other trees

12
Semantics

• When are whose updates exposed to which other
  transactions?
• If theres a conflict, how far to roll back?

13
Closed Transactions

• Dont redo more than needed
• Partial roll back
• Only as far as required to resolve the conflict
• Performance enchancement

14
Closed Abort

• How far back to abort?
• Individual read and write sets
• Roll back through oldest that conflicts
• Partial abort
• Roll back individual versions
• Discard read and write sets

15
Closed Commit

• Commit
• After commit, looks as though was subsumed
• If parent rolls back, it rolls back committed
  childrens effects too
• Merge read and write sets and versions into
  parents on commit

16
Closed Data Visibility

• Updates made visible
• To other transactions in the same tree, as soon
  as they occur
• To other trees, only when the top-level
  transaction commits

17
Open Transactions

• Same as closed, but additionally
• On inner commit
• Discard read and write sets
• Push writes through to global state
• Updates made visible
• To other trees, as soon as the running
  transaction commits
• Goal increased concurrency

18
Applications

• Highly concurrent indexes collections
• Memory allocation garbage collection
• Scheduler queue operations
• External activities (I/O)

19
Intended Use

• Open transaction represents a single logical
  operation at a higher level of abstraction
• At that level, it should have a compensating
  action
• A semantic undo, as opposed to undo by backing
  out the component low-level writes

20
Ancestor abort

• Parent executes the opens compensating action
• As part of its rollback
• When?
• Atomically?
• Hardware support?
• Open transaction should update some state so the
  parent knows what this is

21
Inter-tree Dependences

• How to compensate for effects on other trees?
• Software should provide locking at the higher
  level of abstraction to proactively prevent
• Still increasing concurrency?
• Open transaction should also manipulate this state

22
Intra-tree Overlap

• Running transactions write set overlaps ancestor
  read or write sets
• Bad abstraction violation
• Open commit removes all written elements from
  read and write sets of all ancestors
• To break dependences
• Programmer can always reinstate them at a higher
  level of abstraction

23
Non-linear Nesting

• Within a single tree
• Multiple transactions per level live
• Multiple transactions running
• Execute single tree concurrently!
• Map to threads and processors?

24
Versions Conflicts

• Versions
• Still need one per live transactions, but now can
  have more live transactions
• Conflicts
• Still have conflicts among trees
• Now additionally have within a tree
• Can conflict with any transaction thats not a
  direct ancestor (sibilings, uncles)

25
Summary Conclusions

• Nested transactions
• Linear nesting
• Closed semantics
• Open semantics
• Non-linear nesting
• Do we agree with these?
• Need hardware implementations
• What subset to provide?