software transactions: a programming-languages perspective

Software Transactions: A Programming-Languages Perspective

Dan GrossmanUniversity of Washington

26 March 2008

26 March 2008 Dan Grossman, Software Transactions 2

Atomic

An easier-to-use and harder-to-implement primitive

lock acquire/release (behave as if)no interleaved computation

void deposit(int x){synchronized(this){ int tmp = balance; tmp += x; balance = tmp;}}

void deposit(int x){atomic { int tmp = balance; tmp += x; balance = tmp; }}


Viewpoints

Software transactions good for:• Software engineering (avoid races & deadlocks)• Performance (optimistic “no conflict” without locks)

Research should be guiding:• New hardware with transactional support• Software support

– Semantic mismatch between language & hardware– Prediction: hardware for the common/simple case– May be fast enough without hardware– Lots of nontransactional hardware exists


PL Perspective

Complementary to lower-level implementation work

Motivation:– The essence of the advantage over locks

Language design: – Rigorous high-level semantics– Interaction with rest of the language

Language implementation: – Interaction with modern compilers – New optimization needs

Answers urgently needed for the multicore era


Today, part 1

Language design, semantics:

1. Motivation: Example + the GC analogy [OOPSLA07]

2. Semantics: strong vs. weak isolation [PLDI07]* [POPL08]

3. Interaction w/ other features [ICFP05][SCHEME07][POPL08]

* Joint work with Intel PSL


Today, part 2

Implementation:

4. On one core [ICFP05][SCHEME07]

5. Static optimizations for strong isolation [PLDI07]*

6. Multithreaded transactions



Code evolution

void deposit(…) { synchronized(this) { … }}void withdraw(…) { synchronized(this) { … }}int balance(…) { synchronized(this) { … }}


Code evolution


void transfer(Acct from, int amt) {

if(from.balance()>=amt && amt < maxXfer) { from.withdraw(amt); this.deposit(amt); } }


Code evolution


void transfer(Acct from, int amt) { synchronized(this) { //race if(from.balance()>=amt && amt < maxXfer) { from.withdraw(amt); this.deposit(amt); } }}


Code evolution


void transfer(Acct from, int amt) { synchronized(this) { synchronized(from) { //deadlock (still) if(from.balance()>=amt && amt < maxXfer) { from.withdraw(amt); this.deposit(amt); } }}}


Code evolution

void deposit(…) { atomic { … }}void withdraw(…) { atomic { … }}int balance(…) { atomic { … }}


Code evolution


void transfer(Acct from, int amt) { //race if(from.balance()>=amt && amt < maxXfer) { from.withdraw(amt); this.deposit(amt); } }


Code evolution


void transfer(Acct from, int amt) { atomic { //correct and parallelism-preserving! if(from.balance()>=amt && amt < maxXfer){ from.withdraw(amt); this.deposit(amt); } }}


But can we generalize

So transactions sure looks appealing…

But what is the essence of the benefit?

Transactional Memory (TM) is to shared-memory concurrency

as Garbage Collection (GC) is to

memory management


GC in 60 seconds

Automate deallocation via reachability approximation

roots heap objects

• Allocate objects in the heap• Deallocate objects to reuse heap space

– If too soon, dangling-pointer dereferences– If too late, poor performance / space exhaustion


GC Bottom-line

Established technology with widely accepted benefits

• Even though it can perform arbitrarily badly in theory

• Even though you can’t always ignore how GC works (at a high-level)

• Even though an active research area after 40+ years

Now about that analogy…


The problem, part 1

Why memory management is hard:

Balance correctness (avoid dangling pointers)

And performance (space waste or exhaustion)

Manual approaches require whole-program protocols Example: Manual reference count for each object

• Must avoid garbage cycles

race conditions

concurrent programming

loss of parallelism deadlock

lock

lock acquisition


The problem, part 2

Manual memory-management is non-modular:

• Caller and callee must know what each other access or deallocate to ensure right memory is live

• A small change can require wide-scale code changes – Correctness requires knowing what data

subsequent computation will access

synchronization

locks are heldrelease

concurrent


The solution

Move whole-program protocol to language implementation• One-size-fits-most implemented by experts

– Usually inside the compiler and run-time

• GC system uses subtle invariants, e.g.:– Object header-word bits

– No unknown mature pointers to nursery objectsthread-shared thread-local

TM


So far…

memory management concurrencycorrectness dangling pointers racesperformance space exhaustion deadlockautomation garbage collection transactional memorynew objects nursery data thread-local data


Incomplete solution

GC a bad idea when “reachable” is a bad approximation of “cannot-be-deallocated”

Weak pointers overcome this fundamental limitation– Best used by experts for well-recognized idioms

(e.g., software caches)

In extreme, programmers can encode

manual memory management on top of GC– Destroys most of GC’s advantages

TM memory conflict

run-in-parallelOpen nested txns

unique id generation

locking TM

TM


Circumventing TM

class SpinLock { private boolean b = false; void acquire() { while(true)

atomic { if(b) continue; b = true; return; } } void release() { atomic { b = false; } }}


It really keeps going (see the essay)

memory management concurrencycorrectness dangling pointers racesperformance space exhaustion deadlockautomation garbage collection transactional memorynew objects nursery data thread-local data

key approximation reachability memory conflictsmanual circumvention weak pointers open nestingcomplete avoidance object pooling lock libraryuncontrollable approx. conservative collection false memory conflictseager approach reference-counting update-in-placelazy approach tracing update-on-commitexternal data I/O of pointers I/O in transactionsforward progress real-time obstruction-freestatic optimizations liveness analysis escape analysis


Lesson

Transactional memory is to

shared-memory concurrency

as

garbage collection is to

memory management

Huge but incomplete help for correct, efficient software

Analogy should help guide transactions research


Today, part 1




[[Katherine Moore]




“Weak” isolation

Widespread misconception:

“Weak” isolation violates the “all-at-once” property only if corresponding lock code has a race

(May still be a bad thing, but smart people disagree.)

atomic { y = 1; x = 3; y = x;}

x = 2;print(y); //1? 2? 666?

initially y==0


It’s worse

Privatization: One of several examples where lock code works and weak-isolation transactions do not

(Example adapted from [Rajwar/Larus] and [Hudson et al])

sync(lk) { r = ptr; ptr = new C();}assert(r.f==r.g);

sync(lk) { ++ptr.f; ++ptr.g;}

initially ptr.f == ptr.gptr

f g


It’s worse

(Almost?) every published weak-isolation system lets the assertion fail!

• Eager-update or lazy-update

atomic { r = ptr; ptr = new C();}assert(r.f==r.g);

atomic { ++ptr.f; ++ptr.g;}

initially ptr.f == ptr.g

ptr

f g


The need for semantics

• Which is wrong: the privatization code or the transactions implementation?

• What other “gotchas” exist? – What language/coding restrictions suffice to avoid

them?

• Can programmers correctly use transactions without understanding their implementation?– What makes an implementation correct?

Only rigorous source-level semantics can answer


What we did

Formal operational semantics for a collection of similar languages that have different isolation properties

Program state allows at most one live transaction:

a;H;e1|| … ||en a’;H’;e1’|| … ||en’

Multiple languages, including:


What we did



a;H;e1|| … ||en a’;H’;e1’|| … ||en’


1. “Strong”: If one thread is in a transaction, no other thread may use shared memory or enter a transaction


What we did



a;H;e1|| … ||en a’;H’;e1’|| … ||en’


2. “Weak-1-lock”: If one thread is in a transaction, no other thread may enter a transaction


What we did



a;H;e1|| … ||en a’;H’;e1’|| … ||en’


3. “Weak-undo”: Like weak, plus a transaction may abort at any point, undoing its changes and restarting


A family

Now we have a family of languages:

“Strong”: … other threads can’t use memory or start transactions

“Weak-1-lock”: … other threads can’t start transactions “Weak-undo”: like weak, plus undo/restart

So we can study how family members differ and conditions under which they are the same

Oh, and we have a kooky, ooky name:

The AtomsFamily


Easy Theorems

Theorem: Every program behavior in strong is possible in weak-1-lock

Theorem: weak-1-lock allows behaviors strong does not

Theorem: Every program behavior in weak-1-lock is possible in weak-undo

Theorem (slightly more surprising): weak-undo allows behavior weak-1-lock does not


Hard theorems

Consider a (formally defined) type system that ensures any mutable memory is either:– Only accessed in transactions– Only accessed outside transactions

Theorem: If a program type-checks, it has the same possible behaviors under strong and weak-1-lock

Theorem: If a program type-checks, it has the same possible behaviors under weak-1-lock and weak-undo


A few months in 1 picture

strong weak-1-lock weak-undo

strong-undo


Lesson

Weak isolation has surprising behavior;

formal semantics let’s us model the behavior and

prove sufficient conditions for avoiding it

In other words: With a (too) restrictive type system, get semantics of strong and performance of weak


Today, part 1







What if…

Real languages need precise semantics for all feature interactions. For example:

• Native Calls [Ringenburg]• Exceptions [Ringenburg, Kimball]• First-class continuations [Kimball]• Thread-creation [Moore]• Java-style class-loading [Hindman]

• Open: Bad interactions with memory-consistency model

See joint work with Manson and Pugh [MSPC06]


Today, part 2

Implementation:

4. On one core [ICFP05] [SCHEME07]

[Michael Ringenburg, Aaron Kimball]





Interleaved execution

The “uniprocessor (and then some)” assumption:

Threads communicating via shared memory don't execute in “true parallel”

Important special case:• Uniprocessors still exist• Many language implementations assume it

(e.g., OCaml, Scheme48)• Multicore may assign one core to an application


Implementing atomic

Key pieces:

• Execution of an atomic block logs writes

• If scheduler pre-empts during atomic, rollback the thread

• Duplicate code or bytecode-interpreter dispatch so non-atomic code is not slowed by logging


Logging example

Executing atomic block:• build LIFO log of old values:

y:0 z:? x:0 y:2

Rollback on pre-emption:• Pop log, doing assignments• Set program counter and

stack to beginning of atomic

On exit from atomic: • Drop log

int x=0, y=0;void f() { int z = y+1; x = z;}void g() { y = x+1;}void h() { atomic { y = 2; f(); g(); }}


Logging efficiency

Keep the log small:• Don’t log reads (key uniprocessor advantage)• Need not log memory allocated after atomic entered

– Particularly initialization writes• Need not log an address more than once

– To keep logging fast, switch from array to hashtable after “many” (50) log entries

y:0 z:? x:0 y:2


Evaluation

Strong isolation on uniprocessors at little cost – See papers for “in the noise” performance

• Memory-access overhead

Recall initialization writes need not be logged

• Rare rollback

not in atomic in atomic

read none none

write none log (2 more writes)


Lesson

Implementing transactions in software for a uniprocessor is so efficient it deserves special-casing

Note: Don’t run other multicore services on a uniprocessor either


Today, part 2

Implementation:



[Steven Balensiefer, Benjamin Hindman]




Strong performance problem

Recall uniprocessor overhead:


read none none

write none some

With parallelism:


read none iff weak some

write none iff weak some


Optimizing away strong’s cost

Thread local

Immutable

Not accessed in transaction

New: static analysis for not-accessed-in-transaction …


Not-accessed-in-transaction

Revisit overhead of not-in-atomic for strong isolation, given information about how data is used in atomic

Yet another client of pointer-analysis

in atomic

no atomic access

no atomic write

atomic write

read none none some some

write none some some some

not in atomic


Analysis details

• Whole-program, context-insensitive, flow-insensitive– Scalable, but needs whole program

• Can be done before method duplication– Keep lazy code generation without losing precision

• Given pointer information, just two more passes

1. How is an “abstract object” accessed transactionally?

2. What “abstract objects” might a non-transactional access use?


Collaborative effort

• UW: static analysis using pointer analysis– Via Paddle/Soot from McGill

• Intel PSL: high-performance STM – Via compiler and run-time

Static analysis annotates bytecodes, so the compiler back-end knows what it can omit


Benchmarks

0.00

1.00

2.00

3.00

4.00

5.00

6.00

1 2 4 8 16

# Threads

Tim

e (

s)

Synch Weak Atom Strong Atom No Opts +JIT Opts +DEA +Static Opts

Tsp


Benchmarks

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

1 2 4 8 16

# Threads

Ave

rag

e ti

me

per

10,

000

op

s (s

)

Synch Weak Atom Strong Atom No Opts +JIT Opts +DEA +Static Opts

JBB


Lesson

The cost of strong isolation is in the nontransactional code; compiler optimizations help a lot


Today, part 2

Implementation:



6. Multithreaded transactions [Aaron Kimball]

Caveat: ongoing work



Multithreaded Transactions

• Most implementations (hw or sw) assume code inside a transaction is single-threaded– But isolation and parallelism are orthogonal– And Amdahl’s Law will strike with manycore

• Language design: need nested transactions

• Currently modifying Microsoft’s Bartok STM– Key: correct logging without sacrificing parallelism

• Work perhaps ahead of the technology curve– like concurrent garbage collection


Credit

Semantics: Katherine MooreUniprocessor: Michael Ringenburg, Aaron KimballOptimizations: Steven Balensiefer, Ben HindmanImplementing multithreaded transactions: Aaron Kimball

Memory-model issues: Jeremy Manson, Bill PughHigh-performance strong STM: Tatiana Shpeisman,

Vijay Menon, Ali-Reza Adl-Tabatabai, Richard Hudson, Bratin Saha

wasp.cs.washington.edu


Please read

High-Level Small-Step Operational Semantics for Transactions [POPL08] Katherine F. Moore, Dan Grossman

The Transactional Memory / Garbage Collection Analogy [OOPSLA07] Dan Grossman

Software Transactions Meet First-Class Continuations [SCHEME07] Aaron Kimball, Dan Grossman

Enforcing Isolation and Ordering in STM [PLDI07] Tatiana Shpeisman, Vijay Menon, Ali-Reza Adl-Tabatabai, Steve Balensiefer, Dan Grossman, Richard Hudson, Katherine F. Moore, Bratin Saha Atomicity via Source-to-Source Translation [MSPC06] Benjamin Hindman and Dan GrossmanWhat Do High-Level Memory Models Mean for Transactions?

[MSPC06] Dan Grossman, Jeremy Manson, William PughAtomCaml: First-Class Atomicity via Rollback [ICFP05] Michael F. Ringenburg, Dan Grossman


Lessons

1. Transactions: the garbage collection of shared memory

2. Semantics: prove sufficient conditions for avoiding weak-isolation anomalies

3. Must define interaction with features like exceptions

4. Uniprocessor implementations are worth special-casing

5. Compiler optimizations help remove the overhead in nontransactional code resulting from strong isolation

6. Amdahl’s Law suggests multithreaded transactions, which we believe we can make scalable

software transactions: a programming-languages perspective

Documents