A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L. Scott.

Slides:



Advertisements
Similar presentations
Time-based Transactional Memory with Scalable Time Bases Torvald Riegel, Christof Fetzer, Pascal Felber Presented By: Michael Gendelman.
Advertisements

Concurrent programming for dummies (and smart people too) Tim Harris & Keir Fraser.
Software Transactional Memory and Conditional Critical Regions Word-Based Systems.
1 Lecture 18: Transactional Memories II Papers: LogTM: Log-Based Transactional Memory, HPCA’06, Wisconsin LogTM-SE: Decoupling Hardware Transactional Memory.
Code Generation and Optimization for Transactional Memory Construct in an Unmanaged Language Programming Systems Lab Microprocessor Technology Labs Intel.
IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1.
Transactional Locking Nir Shavit Tel Aviv University (Joint work with Dave Dice and Ori Shalev)
Lock-Based Concurrency Control
Virendra J. Marathe, William N. Scherer III, and Michael L. Scott Department of Computer Science University of Rochester Presented by: Armand R. Burks.
Software Transactional Memory Kevin Boos. Two Papers Software Transactional Memory for Dynamic-Sized Data Structures (DSTM) – Maurice Herlihy et al –
Toward High Performance Nonblocking Software Transactional Memory Virendra J. Marathe University of Rochester Mark Moir Sun Microsystems Labs.
Concurrent Programming Without Locks Keir Fraser & Tim Harris Adapted from an earlier presentation by Phil Howard.
Pessimistic Software Lock-Elision Nir Shavit (Joint work with Yehuda Afek Alexander Matveev)
Transactional Memory: Architectural Support for Lock- Free Data Structures Herlihy & Moss Presented by Robert T. Bauer.
Ali Saoud Object Based Transactional Memory. Introduction Resent trends go towards object based SMT because it’s dynamic Word-based STM systems are more.
Thread-Level Transactional Memory Decoupling Interface and Implementation UW Computer Architecture Affiliates Conference Kevin Moore October 21, 2004.
1 Lecture 12: Hardware/Software Trade-Offs Topics: COMA, Software Virtual Memory.
PARALLEL PROGRAMMING with TRANSACTIONAL MEMORY Pratibha Kona.
TOWARDS A SOFTWARE TRANSACTIONAL MEMORY FOR GRAPHICS PROCESSORS Daniel Cederman, Philippas Tsigas and Muhammad Tayyab Chaudhry.
1 Lecture 21: Transactional Memory Topics: consistency model recap, introduction to transactional memory.
[ 1 ] Agenda Overview of transactional memory (now) Two talks on challenges of transactional memory Rebuttals/panel discussion.
EPFL - March 7th, 2008 Interfacing Software Transactional Memory Simplicity vs. Flexibility Vincent Gramoli.
Transaction Management and Concurrency Control
Computer Laboratory Practical non-blocking data structures Tim Harris Computer Laboratory.
1 Lecture 24: Transactional Memory Topics: transactional memory implementations.
Software Transactional Memory for Dynamic-sized Data Structures Maurice Herlihy, Victor Luchango, Mark Moir, William N. Scherer III Presented by: Irina.
Supporting Nested Transactional Memory in LogTM Authors Michelle J Moravan Mark Hill Jayaram Bobba Ben Liblit Kevin Moore Michael Swift Luke Yen David.
Language Support for Lightweight transactions Tim Harris & Keir Fraser Presented by Narayanan Sundaram 04/28/2008.
1 Lecture 9: TM Implementations Topics: wrap-up of “lazy” implementation (TCC), eager implementation (LogTM)
Software Transaction Memory for Dynamic-Sized Data Structures presented by: Mark Schall.
1 Lecture 7: Lazy & Eager Transactional Memory Topics: details of “lazy” TM, scalable lazy TM, implementation details of eager TM.
Concurrent Programming Without Locks Keir Fraser & Tim Harris.
KAUSHIK LAKSHMINARAYANAN MICHAEL ROZYCZKO VIVEK SESHADRI Transactional Memory: Hybrid Hardware/Software Approaches.
Transactions and Reliability. File system components Disk management Naming Reliability  What are the reliability issues in file systems? Security.
An Introduction to Software Transactional Memory
Software Transactional Memory for Dynamic-Sized Data Structures Maurice Herlihy, Victor Luchangco, Mark Moir, William Scherer Presented by: Gokul Soundararajan.
Reduced Hardware NOrec: A Safe and Scalable Hybrid Transactional Memory Alexander Matveev Nir Shavit MIT.
Transactional Memory Lecturer: Danny Hendler.  Speeding up uni-processors is harder and harder  Intel, Sun (RIP), AMD, IBM now focusing on “multi-core”
CS5204 – Operating Systems Transactional Memory Part 2: Software-Based Approaches.
Lecture 12 Recoverability and failure. 2 Optimistic Techniques Based on assumption that conflict is rare and more efficient to let transactions proceed.
Concurrency Server accesses data on behalf of client – series of operations is a transaction – transactions are atomic Several clients may invoke transactions.
Lowering the Overhead of Software Transactional Memory Virendra J. Marathe, Michael F. Spear, Christopher Heriot, Athul Acharya, David Eisenstat, William.
Low-Overhead Software Transactional Memory with Progress Guarantees and Strong Semantics Minjia Zhang, 1 Jipeng Huang, Man Cao, Michael D. Bond.
On the Performance of Window-Based Contention Managers for Transactional Memory Gokarna Sharma and Costas Busch Louisiana State University.
Transactional Memory Lecturer: Danny Hendler. 2 2 From the New York Times…
Optimistic Methods for Concurrency Control By: H.T. Kung and John Robinson Presented by: Frederick Ramirez.
Wait-Free Multi-Word Compare- And-Swap using Greedy Helping and Grabbing Håkan Sundell PDPTA 2009.
Software Transactional Memory Should Not Be Obstruction-Free Robert Ennals Presented by Abdulai Sei.
A Methodology for Implementing Highly Concurrent Data Objects by Maurice Herlihy Slides by Vincent Rayappa.
Transactional Memory Student Presentation: Stuart Montgomery CS5204 – Operating Systems 1.
Hazard Pointers: Safe Memory Reclamation for Lock-Free Objects MAGED M. MICHAEL PRESENTED BY NURIT MOSCOVICI ADVANCED TOPICS IN CONCURRENT PROGRAMMING,
Concurrent Programming Without Locks Based on Fraser & Harris’ paper.
Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III
Maurice Herlihy and J. Eliot B. Moss,  ISCA '93
Database Recovery Techniques
Minh, Trautmann, Chung, McDonald, Bronson, Casper, Kozyrakis, Olukotun
Part 2: Software-Based Approaches
Transaction Management and Concurrency Control
Two Ideas of This Paper Using Permissions-only Cache to deduce the rate at which less-efficient overflow handling mechanisms are invoked. When the overflow.
Maurice Herlihy, Victor Luchangco, Mark Moir, William N. Scherer III
A Qualitative Survey of Modern Software Transactional Memory Systems
Lecture 6: Transactions
Part 1: Concepts and Hardware- Based Approaches
Hybrid Transactional Memory
Introduction of Week 13 Return assignment 11-1 and 3-1-5
Concurrent Programming Without Locks
Lecturer: Danny Hendler
Lecture 23: Transactional Memory
Dynamic Performance Tuning of Word-Based Software Transactional Memory
Concurrency control (OCC and MVCC)
Presentation transcript:

A Qualitative Survey of Modern Software Transactional Memory Systems Virendra J. Marathe Michael L. Scott

Software Transactional Memory Introduction

● Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization

Introduction ● Herlihy and Moss proposed STM as a novel architectural support mechanism for nonblocking synchronization ● implemented a transactional memory by extending multiprocessor cache coherency protocols ● provided an instruction set for accessing shared memory

Introduction ● We will see ● Software Transactional Memory (Shavit 95) ● Hash Table Based STM (Harris 03) ● Dynamic Software Transactional Memory (DSTM) ● a Lock Free Object Based STM (FSTM) [Fraser 03] ● We will make a qualitative comparison of these implementations

STM, by Shavit and Toitou[1995] The STM Algorithm

STM, by Shavit and Toitou[1995] ● The Transaction lists the memory it needs ● The Transaction attempts to take “ownership” of the needed memory ● If any ownerships cannot be taken, the transaction fails and retries ● Change the state to COMITTED atomically ● Make updates ● Release all ownerships

STM, by Shavit and Toitou[1995] ● A memory word is used as the concurrent object ● Each memory word has a corresponding ownership Record (orec) ● The orec may be NULL (no transaction owns the orec) ● The orec may be a reference to a transaction record

STM, by Shavit and Toitou[1995] MemoryOwnership Records Null Transaction Record

STM, by Shavit and Toitou[1995] ● Helping – used to avoid livelocks – Ownerships are acquired in some global order – if A finds that process B owns a record, A will make B's updates on B's behalf. – helping is done non-recursively

STM, by Shavit and Toitou[1995] ● Drawbacks – To ensure ordered access, one must know all memory words one will access before one starts – each shared memory word requires an orec of equal size. This doubles the memory requirement of STM – There is an efficiency drawback, due to contention overhead during helping.

Hash Table Based STM ● Word based STM ● Uses a hash table for the orecs ● provides an interface to the STM

Hash Table Based STM ● Data Structures – The Application Heap – The Hash Table of orecs – transaction descriptors

Hash Table Based STM ● Application Heap is the shared memory that holds the data the concurrent processes use ● Uses a hash table for the orecs – The shared memory locations hash into the orecs hash table. – Each orec has a version number or a reference to the transaction descriptor of the transaction that currently owns the orec – When a transaction owns an orec it also owns all other memory hashing into that orec!

Transaction Descriptor Ownership Record Application Heap

Hash Table Based STM ● The Interface – void STMStart() – stm_word STMRead( addr a ) – void STMWrite( addr am stm_word w ) – void STMAbort() – boolean STMCommit() – boolean STMValidate() – void STMWait()

Transaction Descriptor Ownership Record Application Heap Before

Transaction Descriptor Ownership Record Application Heap STMRead or STMWrite New Transaction Entry : The Address being accessed Old Value and Version num. New Value and Version num

Transaction Descriptor Ownership Record Application Heap STMCommit Address being accessed Old Value and Version num. New Value and Version num

Transaction Descriptor Ownership Record Application Heap Read Conflict ! Address being accessed Old Value and Version num. New Value and Version num transaction 2

Transaction Descriptor Ownership Record Application Heap Acquire Conflict ! Address being accessed Old Value and Version num. New Value and Version num transaction 2

Hash Table Based STM ● Acquire Conflict : – If the conflicting transaction is ACTIVE the current transaction aborts it. – Then the current transaction verifies the consistency of the version number of the orec under conflict with the latest valid version number in the conflicting transaction's descriptor. If an inconsistency is detected, Abort and release all acquired ownerships – next help or steal

Hash Table Based STM ● Stealing vs Helping – Helping is expensive due to contention – To Steal, the transaction merges the transaction entries corresponding to the orec under conflict into its own transaction descriptor using atomic CAS.

Hash Table Based STM ● Design and Efficiency Issues – Contention management, or polite vs aggressive : polite algorithms perform better – Bounded Memory Blow-Up Problem : When a stealer merges descriptors, the stealer may end up possessing several records it doesn't care about

Hash Table Based STM ● An LL/SC based approach may reduce the effects of the Bounded Memory Blow-Up problem.

Object-based Software Transactional Memory Systems

Dynamic Software Transaction Memory (DSTM)

DSTM ● a Transactional Memory object is a wrapper around the concurrent data object. This contains a pointer to ● a Locator object stores a pointer to a descriptor of the most recent modifying transaction, and to the old and new versions of the data object.

TM Obj. Transaction New Obj Old Obj Transaction New Obj Old Obj Committed Transaction Shared Obj. New Ver. Shared Obj, Old Ver. New Active Transaction Shared Obj, new Vers.Copy

DSTM ● A Transaction Descriptor may be in one of 3 states. These determine the most recent valid version of the data object – ACTIVE: the old version is correct – ABORTED: the old version is correct – COMMITTED : the new version is correct

DSTM ● The locator is not an orec – The locator is referenced by the TM object, the orec is found by a hash function – The locator points to old and new versions of the data, the orec stores a version number or points to a descriptor with the old and new versions of the data – The locator does not require a version number

Object-based Software Transactional Memory Systems Lock-Free Object Based STM (FSTM)

Lock-Free Object Based STM (FSTM) ● Data Structures – Object Header wraps the concurrent object – Transaction Descriptor is used by each transaction to maintain the list of in-use concurrent objects. This object maintains two lists (read only and read write) – Object Handles consist of references to an object header, the concurrent object referenced bu the object header and a shadow copy of the concurrent object.

UNDECIDED Object Ref, old and new data, next handle List of object handles Object HeaderConcurrent Obj.Shadow Copy

Lock-Free Object Based STM (FSTM) ● To access an object – Open the object using that object header – This creates an object handle in that object's descriptor

Lock-Free Object Based STM (FSTM) ● Committing a change – Acquire phase – Decision Point – Release Phase

Lock-Free Object Based STM (FSTM) ● Acquire Phase – Acquire each concurrent object in read-write object handle list. Do so in global total order using atomic CAS – on fail, if the conflict is with a modified object, abort – on fail, if conflict is with an uncommitted transaction, help the conflicting transaction – decide whether to commit or abort

Lock-Free Object Based STM (FSTM) ● READ-CHECKING state – Decide whether the transactions committed or aborted – Begin the read phase, and walk through the descriptor's read-only list – If there is a conflict, verify the data's consistency – if the conflict is with an UNDECIDED transaction, verify the old data in the conflicting object handle. If the data object is different, ABORT

The Qualitative Comparison ● Object Acquire Semantics ● Indirection Overhead ● Space Usage ● Search Overhead ● Contention Management vs Helping ● Transaction Validation

The Qualitative Comparison ● Object Acquire Semantics – Eager Acquire vs Lazy Acquire

The Qualitative Comparison ● Indirection Overhead – DSTM requires n+1 CAS to commit – FSTM and Hash Table require 2N+2 CAS

The Qualitative Comparison ● Space Usage – The space requirement of DSTM is more than twice that of FSTM usually

The Qualitative Comparison ● Search Overhead – FSTM and Hash Table require a search for the concurrent object under conflict – DSTM does not

The Qualitative Comparison ● Contention Management vs Helping – need empirical testing of this

The Qualitative Comparison ● Transaction Validation

Finis