supporting nested transactional memory in logtm
Download
Skip this Video
Download Presentation
Supporting Nested Transactional Memory in LogTM

Loading in 2 Seconds...

play fullscreen
1 / 32

Supporting Nested Transactional Memory in LogTM - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Supporting Nested Transactional Memory in LogTM' - melia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
supporting nested transactional memory in logtm

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
OVERVIEW
  • Common Terms
  • LogTM
  • LogTM with nested Transactions
  • Experiment
  • Conclusion
introduction
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 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

1

1

1

1

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

--

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

--23

Log Based TM

Version Management

  • New values stored in place

(in main memory)

  • Old values stored in a

thread-private transaction log

VA

Data Block

R W

00

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

0

0

40

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

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

0

0

C0

56--------------

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

0

0

LogBase

1000

LogPtr

1090

1000

c0

TMcount

1040

40

1

1080

log based tm2
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)
log based tm3
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
nested logtm
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 logtm1
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
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 logtm1
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 logtm2
Version Management in Nested LogTM
  • The Log Structure

Header

LogBase

LogFrame

Undo record

LogPtr

Undo record

TM count

Header

2

1

Undo record

Undo record

closed nested commit
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

Header

LogFrame

Undo record

LogPtr

Undo record

Header

TM count

1

2

Undo record

Undo record

nested logtm2
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
concurrency
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
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
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
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
escape actions
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
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
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
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
conclusion
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
ad