6.888 PARALLEL AND HETEROGENEOUS COMPUTER ARCHITECTURE

SPRING 2013

LECTURE 12

TRANSACTIONAL MEMORY

DANIEL SANCHEZ AND JOEL EMER

[BASED ON EE382A MATERIAL FROM KOZYRAKIS]

Transactional Memory (TM) 2

Memory transaction [Lomet’77, Knight’86, Herlihy & Moss’93]

An atomic & isolated sequence of memory accesses

Inspired by database transactions

Atomicity (all or nothing)

At commit, all memory writes take effect at once

On abort, none of the writes appear to take effect

Isolation

No other code can observe writes before commit

Serializability

Transactions seem to commit in a single serial order

The exact order is not guaranteed though

6.888 Spring 2013 - Sanchez and Emer - L12

Programming with TM 3

Declarative synchronization

Programmers says what but not how

No explicit declaration or management of locks

System implements synchronization

Typically with optimistic concurrency [Kung’81]

Slow down only on conflicts (R-W or W-W)

void deposit(account, amount){

lock(account);

int t = bank.get(account);

t = t + amount;

bank.put(account, t);

unlock(account);

}

void deposit(account, amount){

atomic {

int t = bank.get(account);

t = t + amount;

bank.put(account, t);

}

}

6.888 Spring 2013 - Sanchez and Emer - L12

Advantages of TM 4

Easy to use synchronization

As easy to use as coarse-grain locks

Programmer declares, system implements

Performs as well as fine-grain locks

Automatic read-read & fine-grain concurrency

No tradeoff between performance & correctness

Failure atomicity & recovery

No lost locks when a thread fails

Failure recovery = transaction abort + restart

Composability

Safe & scalable composition of software modules

6.888 Spring 2013 - Sanchez and Emer - L12

Performance: Locks Vs Transactions 5

0

0.2

0.4

0.6

0.8

1

1 2 4 8 16

Processors

Ex

ec

uti

on

Tim

e

coarse locks fine locks TCC

0

0.5

1

1.5

2

2.5

3

3.5

4

1 2 4 8 16

Processors

Ex

ec

uti

on

Tim

e

coarse locks fine locks TCC

Ba

lan

ce

d T

ree

H

as

hM

ap

TCC: a HW-based TM system

[Hammond et al, ISCA’04]

6.888 Spring 2013 - Sanchez and Emer - L12

TM Implementation Basics 6

TM systems must provide atomicity and isolation without sacrificing concurrency

Basic implementation requirements

Checkpointing

Data versioning

Conflict detection & resolution

Implementation options

Hardware transactional memory (HTM)

Software transactional memory (STM)

Hybrid transactional memory Hardware accelerated STMs and dual-mode systems

6.888 Spring 2013 - Sanchez and Emer - L12

Motivation for Hardware TM 7

Measured single-thread STM performance:

Software TM suffers 2-8x slowdown over sequential

Short term issue: demotivates parallel programming

Long term issue: not energy-efficient

Industry adopting HTM: Sun (Rock), Intel (Haswell), IBM (Blue Gene

and zSeries)

0.0

0.5

1.0

1.5

2.0

kmeans

Execu

tio

n T

ime

(norm

alized to s

equentia

l)

0

1

2

3

4

5

6

vacation

STMwrite

STMread

STMcommit

Busy

6.888 Spring 2013 - Sanchez and Emer - L12

Data Versioning 8

Manage uncommited (new) and commited (old) versions of data for concurrent

transactions

1. Eager versioning (undo-log based)

Update memory location directly

Maintain undo info in a log

+ Faster commit, direct reads (SW)

– Slower aborts, fault tolerance issues

2. Lazy versioning (write-buffer based)

Buffer data until commit in a write-buffer

Update actual memory location on commit

+ Faster abort, no fault tolerance issues

– Slower commits, indirect reads (SW)

6.888 Spring 2013 - Sanchez and Emer - L12

Eager Versioning Illustration 9

Begin Xaction

Thread

X: 10 Memory

Undo

Log

Write X←15

Thread

X: 15 Memory

Undo

Log X: 10

Commit Xaction

Thread

X: 15 Memory

Undo

Log X: 10

Abort Xaction

Thread

X: 10 Memory

Undo

Log X: 10

6.888 Spring 2013 - Sanchez and Emer - L12

Lazy Versioning Illustration 10

Begin Xaction

Thread

X: 10 Memory

Write

Buffer

Write X←15

Thread

X: 10 Memory

Write

Buffer X: 15

Abort Xaction

Thread

X: 10 Memory

Write

Buffer X: 15

Commit Xaction

Thread

X: 15 Memory

Write

Buffer X: 15

6.888 Spring 2013 - Sanchez and Emer - L12

Conflict Detection 11

Detect and handle conflicts between transaction

Read-Write and (often) Write-Write conflicts

Must track the transaction’s read-set and write-set

Read-set: addresses read within the transaction

Write-set: addresses written within transaction

1. Pessimistic (Eager) detection

Check for conflicts during loads or stores

SW: SW barriers using locks and/or version numbers

HW: check through coherence actions

Use contention manager to decide to stall or abort

Various priority policies to handle common case fast

6.888 Spring 2013 - Sanchez and Emer - L12

Pessimistic Detection Illustration 12

Case 1 Case 2 Case 3 Case 4

X0 X1

rd A

wr B

check

check

wr C check

commit

commit

Success

X0 X1

wr A

rd A

check

check

commit

commit

Early Detect

stall

X0 X1

rd A

wr A

check

check

commit

commit

Abort

restart

rd A check

X0 X1

rd A

check

No progress

wr A

rd A wr A

check

restart

rd A

check

wr A

restart

rd A wr A

check

restart

TIM

E

6.888 Spring 2013 - Sanchez and Emer - L12

Conflict Detection (cont) 13

2. Optimistic (Lazy) detection

Detect conflicts when a transaction attempts to commit

SW: validate write/read-set using locks or version numbers

HW: validate write-set using coherence actions

Get exclusive access for cache lines in write-set

On a conflict, give priority to committing transaction

Other transactions may abort later on

On conflicts between committing transactions, use contention manager to

decide priority

Note: optimistic & pessimistic schemes together

Several STM systems are optimistic on reads, pessimistic on writes

6.888 Spring 2013 - Sanchez and Emer - L12

Optimistic Detection Illustration 14

Case 1 Case 2 Case 3 Case 4

X0 X1

rd A

wr B

wr C

commit

commit

Success

X0 X1

wr A

rd A

commit

Abort

restart

X0 X1

rd A

wr A

commit

Success

X0 X1

rd A

Forward progress

wr A

rd A wr A

check

check

check

rd A

check

commit check

commit check

restart

rd A wr A

commit check

TIM

E

commit check

6.888 Spring 2013 - Sanchez and Emer - L12

Conflict Detection Tradeoffs 15

1. Pessimistic conflict detection (aka eager, encounter)

+ Detect conflicts early

• Undo less work, turn some aborts to stalls

– No forward progress guarantees, more aborts in some cases

– Locking issues (SW), fine-grain communication (HW)

2. Optimistic conflict detection (aka lazy, commit)

+ Forward progress guarantees

+ Potentially less conflicts, shorter locking (SW), bulk communication (HW)

– Detects conflicts late, still has fairness problems

6.888 Spring 2013 - Sanchez and Emer - L12