K A U S H I K L A K S H M I N A R A Y A N A N
M I C H A E L R O Z Y C Z K O
V I V E K S E S H A D R I

Transactional Memory




Lock-free data structures
Atomic code sections

Abstraction – what instead of how
Ideas from database community
Means a lot to parallel programming

Hardware vs Software TM



Hardware Transactional Memory (HTM)

Modify cache coherence protocol, ISA extensions


Best-effort (bounded resources)

Transactions cannot exceed processor resources
UTM (unbounded resources)

Supports large transactions – hard to realize
Software Transactional Memory (STM)

Software bookkeeping

Overhead
Hybrid Transactional Memory (?)

Combine benefits of both models

Hybrid TM Design Issues






Naming 
Hardware support
Software mechanism
Policy
ISA extensions
Other issues

HyTM Overview
 HyTM

Peter Damron, Alexandra Fedorova, Yossi Lev, Victor
Luchangco, Mark Moir and Daniel Nussbaum
HyTM Library
Best-effort
HTM
STM

Overview of Implementations II
 RTM

Arvindh Shriraman, Michael F. Spear, Hemayat Hossain,
Virendra J. Marathe, Sandhya Dwarkadas and Michael L. Scott
Application Handler
HTM

Overview of Implementations III
 SigTM

Chi Chao Minh, Martin Trautmann, JaeWoong Chung, Austen
McDonald, Nathan Bronson, Jared Casper, Christos Kozyrakis,
Kunle Olukotun
STM
Hardware
Bookkeeping
(Signatures)

Hardware Support/Software Mechanisms
 HyTM

Does not assume any hardware support


Runs on existing HTM (if one exists)
Full-fledged STM library

Object records (for every word in memory)

Meta-information about the state of the word

Handlers

Conflict management

Hardware/Software interface

Hardware Support/Software Mechanisms
 RTM

Cache coherence protocol modifications – TMESI


Additional registers (transaction metadata)
Application-specific handlers

Conflict detection

Aborted hardware transactions

Hardware Support/Software Mechanisms
 SigTM




Hardware signatures (bookkeeping)

Bloom filter
User-level configuration registers (policy)
Slight modification to cache coherence

Hardware check on signature hits

Software handlers to handle hits (based on policy)
Software write-set bookkeeping

Required to update on successful commit

Policy



Upon conflict/eviction, something must be done to resolve the situation
Conflict detection – write-read, write-write

When to do conflict detection? Eager/Lazy

What to do when conflict encountered? Which to abort.
Retrying aborted transactions


Immediate retry vs. back off
HyTM – hardware vs. software transaction

SigTM – API policy management

RTM Policy
 RTM – flexible policy

Application-specific handlers


Speculative execution
Application can decide to allow read-write and write-write

Programmable Data Isolation (PDI)

Can configure exclusivity of data

Alert on Update (AOU)

Inform application when a conflict/eviction occurs

ISA extensions
 Hybrid TM generally use special instructions to interface compiler and TM hardware

Instructions to delimit beginning and ending of transactions
(Most implementations)


Instructions to set application-specific handlers (RTM)
Instructions to check whether the hardware can read or write
(HyTM)

Update the signatures of addresses (SigTM)

Other Issues





False sharing

Cache lines – unwanted abort and retries
Unnecessarily shared variables

Collecting statistics
Memory allocation/Freeing

Malloc and free in aborted transactions
Deadlocks

Issue with lock based mechanisms
Strong isolation and ordering

Interaction with non-transactional writes

K A U S H I K L A K S H M I N A R A Y A N A N
M I C H A E L R O Z Y C Z K O
V I V E K S E S H A D R I