Supporting Nested Transactional
Memory in LogTM
Authors
Michelle J Moravan
Mark Hill
Jayaram Bobba
Ben Liblit
Kevin Moore
Michael Swift
Luke Yen
David Wood
Presented By
Shweta Padubidri
OVERVIEW





Common Terms
LogTM
LogTM with nested Transactions
Experiment
Conclusion
Introduction

Transactional Memory
–
–

Concurrency control mechanism to control access to shared
memory in concurrent computing
Allows a group of load and store instructions in an atomic
way
Nested Transactional Memory
–
–
a new transaction started by an instruction already inside an
existing transaction
Transaction Isolation: Changes made by nested
transactions are not seen by the 'host' until it is committed.
Transactional Memory System

Transactional Memory Systems Differences
–
(Data) Version Management


–
Eager: record old values “elsewhere”; update “in place”
Lazy: update “elsewhere”; keep old values “in place”
(Data) Conflict Detection


Eager: detect conflict on every read/write
Lazy: detect conflict at end (commit/abort)
Log Based TM
VA
Version Management
–
–
New values stored in place
(in main memory)
Old values stored in a
thread-private transaction log
Data Block
00
12--------------
0
1
0
40
--------------24
--------------23
0
1
0
1
C0
56-------------34--------------
0
0
1
LogBase
1000
LogPtr
1090
1000
c0 34------------
1
1040
-- 40 ------------
TMcount
R W
1080
--23
Log Based TM
Log Based TM

Version Management
–
–
–
–
–
When a commit occurs the LogTM processor clears its
cache’s W bits and resets the thread’s log pointer
Drawback : aborts are slow
Abort: LogTM must undo the transaction by writing old
values back
Reset the R/W bits
Undo proceeds from end of the log to the beginning (LIFO)
Example
Log Based TM

Conflict Detection
–
–
–
–
–
Requesting processor sends a coherence request to the
directory
Directory responds and forwards the request to one or more
processors
Each responding processor examines local state to detect
conflict
Responding processors either ack(no conflict) or
nack(conflict) the request
Requesting processor resolves any conflict
Log Based TM
Nested LogTM

Motivation
–
Facilitating Software Composition

Closed Nesting
–
transactions remain isolated until parent commits
– Partial Aborts improve performance
–
Enhancing Concurrency

Open Nesting
–
–
transactions commit independent of parent
Manages isolation at a higher level of abstraction
Nested LogTM

Motivation (Contd)
–
Escaping to Non-Transactional Systems

Supports calls to lower level non-transactional system (
eg: OS), from within a transaction with escape actions.
Version Management in Nested LogTM

Closed Nesting
–
Flat



–
Nested transactions “flattened” into a single transaction
Only outermost begins/commits are meaningful
Any conflict aborts to outermost transaction
Partial Rollback




Child transaction can be aborted independently
Can avoid costly re-execution of parent transaction
But child merges transaction state with parent on
commit
Most conflicts with child end up affecting the parent
Version Management in Nested LogTM



Flat LogTM’s log is a single frame (Fixed Size header +
undo records)
Nested LogTM’s log is a stack of frames
A frame contains:
–
–
–
–
–
Header (including saved registers and pointer to parent’s frame)
Undo records (block address, old value pairs)
Garbage headers (headers of committed closed transactions)
Commit action records
Compensating action records
Version Management in Nested LogTM

The Log Structure
Header
LogBase
LogFrame
Undo record
LogPtr
TM count
Undo record
1
2
Header
Undo record
Undo record
Closed Nested Commit

Merge child’s log frame with parent’s
–
–
Mark child’s header
as a “garbage header” LogFrame
LogPtr
Copy pointer from child’s
1
2
header to LogFrame TM count
Header
Undo record
Undo record
Header
Undo record
Undo record
Nested LogTM



Flat LogTM detects conflicts with directory
coherence and Read (R ) and Write (W ) bits
in caches
Nested LogTM replicates R/W bits for each
level
Flash-Or circuit merges child and parent R/W
bits
Example
Example
Concurrency

Higher-level atomicity
–
–

Child’s memory updates not undone if parent aborts
Use compensating action to undo the child’s forward
action at a higher-level of abstraction
Higher-level isolation
–
–
–
Release memory-level isolation
Programmer enforce isolation at higher level (e.g., locks)
Use commit action to release isolation at parent commit
Open Nesting

Commit Actions
–

Execute in FIFO order when innermost open
ancestor commits
Compensating Actions
–
–
Discard when innermost open ancestor commits
Execute in LIFO order when ancestor aborts
Open Nesting Condition
Condition O1: An open nested child transaction never
modifies a memory location that has been modified
by any ancestor.
// initialize to 0
counter = 0;
transaction_begin(); // top-level 1
counter++; // counter gets 1
open_begin(); // level 2
counter++; // counter gets 2
open_commit(abort_action(counter--));
...
// Abort and run compensating action
// Expect counter to be restored to 0
...
transaction_commit(); // not executed
Open Nesting in LogTM

Version Management
–
–
–

Open commit pops the most recent frame off the log
(Optionally) add commit and compensating action records
Compensating actions are run by the software abort handler
Conflict Detection
–
–
R/W bits cleared on open commit
No ‘OR’ of the R/W bits occur
Example
Escape Actions






Escape actions are used to implement low-level
functions (eg: exception handlers, debuggers and
other run-time support) but are hidden from high
level programmers
Low level escapes to software that is nontransactional (no atomicity or isolation)
May not invoke a transaction
May register commit and compensating actions
Have no effect on the enclosing transactions
It increases the variety of code that execute within
transactions
Escape Action

Rules Escape Actions need to Obey
–
–
–
Condition X1: No writes to Data Written by
Ancestors
Conditions X2: No Writes to Data Accessed by
Others
Condition X3: No Reads to Data Written by
Others
Escape Action in LogTM

Version Management
–

No changes are made to the log. Read and Write access
coherent memory to return the value from the latest
uncommitted write
Conflict Detection
–
No changes are made to the Read and Write bits

Implements escape actions with a per thread flag, which
disables logging and conflict detection when set.

If an ancestor transaction aborts while the escape action is
running , abort is delayed until the flag is cleared.
Experiment

BTree Micro benchmark
–
–
–
–
Each Thread makes a repeated access to a
shared tree
Lookup Probability(85%) and Insert(15%)
Each insert or lookup is executed as a top level
transaction
New nodes are allocated from a shared free list
using pen and closed nested transaction
B-Tree: Closed Nesting
18
16
14
Speedup
12
Closed-100
Flat-100
Closed-1
Flat-1
10
8
6
4
2
0
0
5
10
15
20
Threads
25
30
35
B-Tree: Open Nesting
18
16
14
Speedup
12
Open-1
Closed-100
Closed-1
10
8
6
4
2
0
0
5
10
15
20
Threads
25
30
35
Conclusion

Closed Nesting (partial rollback)
–
–

Open Nesting
–
–

Easy to implement--segment the transaction log (stack of
log frames)/Replicate R & W bits
Small performance gains for LogTM
Easy to implement--software abort handling allows easy
execution of commit actions and compensating actions
Big performance gains
Escape Actions
–
Provide non-transactional operations inside transactions
Questions
???