Supporting Nested Transactional Memory in LogTM - PowerPoint PPT Presentation

Supporting nested transactional memory in logtm
Download
1 / 32

  • 113 Views
  • Uploaded on
  • Presentation posted in: General

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

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

Download Presentation

Supporting Nested Transactional Memory in LogTM

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 tm1

Log Based TM


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)


Example

Example


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


Log based tm4

Log Based TM


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


Example1

Example


Example2

Example


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


Example3

Example


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


B tree closed nesting

B-Tree: Closed Nesting


B tree open nesting

B-Tree: Open Nesting


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


Questions

Questions

???


  • Login