Supporting nested transactional memory in logtm
This presentation is the property of its rightful owner.
Sponsored Links
1 / 32

Supporting Nested Transactional Memory in LogTM PowerPoint PPT Presentation


  • 97 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

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