KAUSHIK LAKSHMINARAYANANMICHAEL ROZYCZKO

VIVEK SESHADRI

Transactional Memory: Hybrid Hardware/Software

Approaches

Transactional Memory

Lock-free data structuresAtomic code sections

Abstraction – what instead of how

Ideas from database communityMeans 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 supportSoftware mechanismPolicyISA extensionsOther issues

HyTM Overview

HyTM Peter Damron, Alexandra Fedorova, Yossi Lev, Victor

Luchangco, Mark Moir and Daniel Nussbaum

HyTM Library

Best-effortHTM

STM

Overview of Implementations II

RTM Arvindh Shriraman, Michael F. Spear, Hemayat

Hossain, Virendra J. Marathe, Sandhya Dwarkadas and Michael L. Scott

Application

HTM

Handler

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

KAUSHIK LAKSHMINARAYANANMICHAEL ROZYCZKO

VIVEK SESHADRI

Transactional Memory: Hybrid Hardware/Software

Approaches