Supporting Nested Transactional Memory in LogTM

AuthorsMichelle J Moravan Mark HillJayaram Bobba Ben LiblitKevin Moore Michael SwiftLuke 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

Version Management– New values stored in place

(in main memory)– Old values stored in a

thread-private transaction log

12--------------

--------------23

34--------------

00

40

C0

1000

1040

1080

Data BlockVA

0 0

R W

0 0

0 0

40

c0 34------------

-- ------------

--23

--------------24

1

1 1

156--------------

1

1090LogPtr

TMcount

LogBase 1000

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

LogPtr

TM count Header

Undo record

Undo record

Undo record

Undo record

LogBaseLogFrameHeader

21

Closed Nested Commit

Merge child’s log frame with parent’s– Mark child’s header

as a “garbage header”– Copy pointer from child’s

header to LogFrame

LogFrame

LogPtr

TM count

Undo record

Header

Undo record

Undo record

Undo record

12 Header

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 0counter = 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 non-transactional (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

0

2

4

6

8

10

12

14

16

18

0 5 10 15 20 25 30 35

Threads

Speedup Closed-100

Flat-100Closed-1Flat-1

B-Tree: Open Nesting

0

2

4

6

8

10

12

14

16

18

0 5 10 15 20 25 30 35

Threads

Speedup

Open-1Closed-100Closed-1

Conclusion

Closed Nesting (partial rollback)– Easy to implement--segment the transaction log (stack of

log frames)/Replicate R & W bits– Small performance gains for LogTM

Open Nesting– 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

???