Software Transactional Objects

Guy EddonMaurice Herlihy

TRAMP 2007

2

Language/Library supportfor Transactions

• Lots of worn on unmanaged languages– “word-based”

• What about managed languages?– Objects, GC, bounds checks,

structured exceptions?– Java™, C#?

• Different concerns

3

Prior STM Work

• Awkward user interface– Long-lived transactional “wrappers” vs– Short-lived “versions”

• Programmer conventions– List element points to wrapper which

points to list ….– Don’t use short-lived objects beyond

lifetime ….

4

public class List { public int item; public TMObject<List> next;}

Old-School Atomic Classes

Next field is explicit wrapper

5

List next = list.next.OpenRead();

Old-School Atomic Classes

Explicit open(specify read or write)

6

List next = list.next.OpenRead();

Old-School Atomic Classes

Must discard after transaction, don’t modify,

etc…

7

List rVersion = list.next.OpenRead();

Old-School Atomic Classes

Read version unchangedRead

version changed

List wVersion = list.next.OpenWrite();wVersion.item++;

List wVersion = list.next.OpenWrite();

List rVersion = list.next.OpenRead();

8Software Transactional Memory

Library approach

• Intercept field accesses– SXM (C#)– DSTM2 (Java™)

• Programmer use factories– Input is interface– Synthesize code to intercept field

accesses

9

Examples

node.Key = 42; // C# property style

Node.setKey(42); // Java EJB style

10

Examples

node.Key = 42; // C# property style

Node.setKey(42); // Java EJB style

try { T version = (T) start.get().newVersion; final Method method = version.getClass().getMethod(methodName, _class); return new Adapter.Setter<V>() { public void call(V value) { try { ThreadState state = Thread.getLocalState(); …

11

Advantages

• Strong Atomicity– Detects transactional/non-

transactional race conditions

• Natural programming style– Almost sequential– No complex conventions

12

Disadvantages

• Efficiency, efficiency, efficiency– Even with fast-path optimizations

• Solution– Use flow analysis to remove

synchronization– Use MSFT Phoenix compiler

13

Lock-Based Runtime

0

200,000

400,000

600,000

800,0001,000,000

1,200,000

1,400,000

SXM 1

.1

Libr

ary

Opts

Compil

er

Cons

tLo

cal

RWPr

omo

Subs

eque

nt

PreO

pen

List

RBTree

SkipList

HashTable

Buff er

14

Obstruction-Free Run-Time

0

200,000

400,000

600,000

800,000

1,000,000

SXM 1

.1

Libr

ary

Opts

Compil

er

Cons

tLo

cal

RWPr

omo

Subs

eque

nt

PreO

pen

List

RBTree

SkipList

HashTable

Buff er

15

Locking vs Obstruction-Free

0

50,000

100,000

150,000

200,000

Ofree

Locking

16

Conclusions

• Managed languages are also important

• Simple flow analysis goes a long way

• Do not rule out non-blocking algorithms yet

17

Clip Art