15
[ 1 ] Agenda Overview of transactional memory (now) Two talks on challenges of transactional memory Rebuttals/panel discussion

[ 1 ] Agenda Overview of transactional memory (now) Two talks on challenges of transactional memory Rebuttals/panel discussion

  • View
    216

  • Download
    2

Embed Size (px)

Citation preview

[ 1 ][ 1 ]

Agenda

Overview of transactional memory (now)

Two talks on challenges of transactional memory

Rebuttals/panel discussion

Transactional Memory Overview

Colin Blundell, E Christopher Lewis, Milo MartinUniversity of Pennsylvania

{blundell, lewis, milom}@cis.upenn.edu

[ 3 ][ 3 ]

The Challenge of Multithreaded SW

Goal: Parallelization

Problem: Unrestricted concurrency bugs

Solution: Synchronization

New problem: Synchronization• Tension between performance and correctness

[ 4 ][ 4 ]

Current Mechanism: Locks

Locks: objects only one thread can hold at a time• Organization: lock for each shared structure

• Usage: (block) acquire access release

Correctness issues• Under-locking data races• Acquires in different orders deadlock

Performance issues• Conservative serialization• Overhead of acquiring• Difficult to find right granularity• Blocking

Correctness, efficiency, simplicity: choose two

[ 5 ][ 5 ]

Enter Transactions

Code segments with three features:

a) Atomicity

b) Serialization only on conflicts

c) Rollback support

[ 6 ][ 6 ]

Transactions vs. Locks

Lock issues:– Under-locking– Acquires in different orders– Blocking– Conservative serialization

How transactions help:+ Simpler interface+ No ordering+ Can cancel transactions+ Serialization only on conflicts

Locks simplicity/performance tensionTransactions (potentially) simple and efficient

[ 7 ][ 7 ]

Agenda

• Transactions: what all the hoopla’s about• Research Proposals

• Usages• Implementations

Disclaimer 1: Covering only hardware supportDisclaimer 2: Purely an overview

[ 8 ][ 8 ]

Execution Strategy

Four main components:

1. Logging/buffering

2. Conflict detection

3. Abort/rollback

4. Commit

Many implementation approaches

[ 9 ][ 9 ]

Transactional Memory (TM)

Goal: lock-free data structures

Approach: multi-location atomic sequences (transactions)

Implementation: special caches + traditional CC protocol• Buffering? Transactional cache• Conflict detection? Cache interventions• Rollback? Invalidate transactional cache• Commit? Validate transactional cache

Transactions limited• Bounded size• Can’t survive interrupts• No I/O

[Herlihy & Moss, ISCA ‘93]

[ 10 ][ 10 ]

Transactional Lock Removal (TLR)

Goal: Lock-based code that serializes only on conflicts

Approach: Execute critical sections as transactions• Dynamically identify acquire/release pairs• Handle conflicts using timestamps (no locks)

Implementation: Buffer in caches + coherence protocol

Reverts to locks in rare cases • I/O• Resource exhaustion • Interrupts

[Rajwar & Goodman, ASPLOS ‘02]

[ 11 ][ 11 ]

Transactional Coherence and Consistency (TCC)

Goal (1): Transactions for synchronization and parallelization

Goal (2): Eliminate traditional cache coherence protocols

Approach: All code in transactions• Communication via transactions’ write packets• Cache coherence at transaction-level granularity

Programming model features• Primitives for speculative parallelization• Unbounded transactions and I/O via “early commit”

[Hammond+, ISCA ‘04 & ASPLOS ‘04]

[ 12 ][ 12 ]

Unbounded Transactional Memory

Goal: Transactions for general-purpose synchronization

Approach: In-progress transactions part of architected state+ Unbounded & persistent transactions– Implementation difficulties (only abstract design)

Compromise: LTM (caches + overflow table in memory)+ More practical implementation– Transactions can’t survive interrupts

[Ananian+, HPCA ‘05]

[ 13 ][ 13 ]

Recent Proposals

Virtualized Transactional Memory (VTM) [Rajwar+, ISCA ‘05]

• Goal: persistent transactions with less overhead• Approach: group transactions by process• Implementation: buffer in cache + overflow table in

virtual memory + various interesting optimizations• Go to talk!

Thread-Level Transactional Memory (TTM) [Moore+, TR ‘05]

[ 14 ][ 14 ]

Summary

Transactions: Promising approach to synchronization• Simple interface + efficient implementation• Uses: optimistic lock removal, lock-free data

structures, general-purpose synchronization, parallelization, ??

Challenges• Implementation• Interface• OS involvement• I/O + rollback• See next two talks

[ 15 ][ 15 ]

References

Ananian+. Unbounded Transactional Memory. (HPCA 2005)Hammond+. Transactional Coherence & Consistency. (ISCA 2004)Hammond+. Programming with Transactional Coherence & Consistency (TCC). (ASPLOS 2004)Herlihy & Moss. Transactional Memory: Architectural Support for Lock-Free Data Structures. (ISCA 1993)Moore+. Thread-Level Transactional Memory. (UW TR 2005)Rajwar & Goodman. Transactional Lock-Free Execution of Lock-Base Programs. (ASPLOS 2004)

Rajwar+. Virtualizing Transactional Memory. (ISCA 2005)

http://www.cs.wisc.edu/trans-memory