Interfacing Software Transactional Memory Simplicity vs. Flexibility

EPFL - March 7th, 2008

Interfacing Software Transactional Memory

Simplicity vs. Flexibility

Vincent Gramoli


Multi-core Motivations

1. Transistor size allows multi-core




2. Processor speed is power-consuming




2. Processor speed is power-consuming

3. Limiting computation speed


Software Transactional Memory Motivations

• Simplicity while handling efficiently parallelism:– Avoiding inefficient coarse-grained locking– Avoiding tricky fine-grained locking– Allowing composition of transactions– Providing transparency to programmer

• Here it is: Software Transactional Memory– Execute code optimistically– Detect conflict when it occurs– Roll-back in case it aborts


Goal

Making STM simple and flexible!

1. Making STM simple:

Any programmer should be able to use it

2. Making STM flexible:

STM should be efficient in any situations


Overview

1. Preliminaries

2. Making STM easy-to-use

3. Making STM flexible

4. Reconciling simplicity and flexibility


What is an interface?

“The interactions of an object with the outside world.”

[java.sun.com]


Interfacing STM

Application STM

beginTransaction()

endTransaction()


Interfacing STM

Application STM

beginTransaction()

endTransaction()

onAbort()

onCommit()

Abort handler

Commit handler


Interfacing STM

1. Is the abort handler part of the STM?

2. Is the commit handler part of the Application?

3. What should be defined explicitly?


Overview

1. Preliminaries





Guards

Explicit Semantic [Harris, Fraser in OOPSLA’03]:

If* (B) Do (A)

where A is the atomic block, B is a boolean (guard)

* can also act as a “wait” (e.g. B=!full_stack)

Implicit Requirement:

Implicit maximum number of retries

B = #retries < ?

How many retries should be made?


Retries

Explicit Semantic [Harris, Marlow, Peyton Jones, Herlihy, PPoPP’05]:

Do (A) If (B) Retry


Implicit roll-back if B is true

Which previous actions should be canceled?


Exceptions

Explicit Semantic [Fetzer, Felber in J.UCS’07]:

Do (A) If (B) Do (C)


Implicit identification of the cause of the exception

How can we prevent this exception to raise again ?


Achieving simplicity

• Every statement must be implicit:– Guard/retry/exception should be handled by the STM

• But, for efficiency purpose we can not:– STM should be tuned so that commit throughput is increased

How to make an STM flexible ?


Overview

1. Preliminaries





Multi-level Interface

NooB Programmer needs Simplicity:

Desire of easy-of-use

Expert Programmer needs Flexbility:

Ability to tune the STM


Dynamic STM 2

[Herlihy, Luchangco, Moir in OOPSLA 2006]

How to use this framework? (NooB programmer)

1. Define your atomic object interface;

2. Pass it to your favorite factory constructor;

3. The factory provides object access;

4. Access the object create/setters/getters.


Dynamic STM 2

My Interface LinkedListNode

Factory

Class LinkedListNode

My Atomic Code


What is tunable?What can be made tunable? • Contention Manager

– Which transaction should abort the other?

• Escape Mechanisms– Could we provide early-release action?

…and so on


Dynamic STM 2

[Herlihy, Luchangco, Moir, OOPSLA 2006]

How to extend this framework? (expert programmer)1. Define your atomic object interface;2. Write your own factory and/or contention manager;3. Pass it to your factory constructor;4. The factory provides object access;5. Access the object create/setters/getters.


Dynamic STM 2


Factory


My FactoryMy FactoryMy FactoryMy Factory

My Atomic Code


Dynamic STM 2


Factory


My FactoryMy FactoryMy FactoryMy Factory

My Atomic Code

My Contention Manager


Dynamic STM 2


Obstruction-freeFactory


My Atomic Code


Dynamic STM 2


ShadowFactory


My Atomic Code


Dynamic STM 2

To conclude:- Especially-suited for object-based STMs;- Indirection is the general mechanism;- STM changes imply interface change.

Can we make it more flexible?





• Data access granularity– Object-/Field-/Word-based

…and so on

DSTM2

DSTM2


Intel STM

transactionalJava

application

transactional memory runtime

transactionalC

application

StarJIT/ ORP JVM

Protoncompiler

SMP systemSimulator

(HW support)

This slide is taken from a talk of Adam Welc [youTube tYRIg4M5xNM]


Intel STM

Write:• Acquire lock on tx-record• Logs old value for roll-back in tx-descriptor• Record value read in read-set of tx-descriptor

Read:• Records value read in read-set of tx-descriptor

Termination:• Validate read-set versions w.r.t. tx-descriptor• Empty read-set, write-set, undo-log


Intel STM

To conclude:- Application language independent - Direct access - Eager update

Can we make it more flexible?


Overview

1. Preliminaries





Simplicity, Basic Interface

interface STMBasicallyUsable {

void beginTransaction()

void commitTransaction()

}


Simplicity, Basic Interface

Application STM

beginTransaction()

endTransaction()


Flexibility, Advanced Interface

interface STMCarefullyUsable extends Tunable {



}


Interfacing STMApplication STM

beginTransaction()

endTransaction()

onAbort()

onCommit()

Abort handler

Commit handler

resolveConflict()

Contentionmanager

store()load()

Memory

abort()

commit()


Flexibility, Advanced Interface

interface STMCarefullyUsable extends Tunable {



}






• Eager/Lazy update– should write operations take effect before commit?

• Direct vs. indirect access– E.g. compare-and-set “pointer to changes” or “lock of changes”?

• Operation visibility – should read operations conflict with operations of other transactions?

…and so on









…and so on

DSTM2

DSTM2









…and so on

DSTM2

DSTM2

Intel STM


Conclusion

Interfaces define the role the STM must play• to maximize performance • to be easy-to-use

Various STM techniques are efficient in different cases:• Direct/Indirect access, • Access granularity,• Contention manager,• Operation visibility, • Eager/Lazy update…

Unifying those techniques in a generic STM:• Simplicity: allows the programmer to choose the one he understands• Flexibility: allows the programmer to choose the one he needs


Open questions

Which techniques are not compatible?e.g. indirection and eager update

How to refine interface to transactions?e.g. one transaction with eager update, another with lazy-update

Could we find the interface to unify all STMs?

Documents

Interfacing Software Transactional Memory Simplicity vs. Flexibility