epfl - march 7th, 2008 interfacing software transactional memory simplicity vs. flexibility vincent...

42
EPFL - March 7th, 2008 Interfacing Software Transactional Memory Simplicity vs. Flexibility Vincent Gramoli

Post on 20-Dec-2015

216 views

Category:

Documents


0 download

TRANSCRIPT

EPFL - March 7th, 2008

Interfacing Software Transactional Memory

Simplicity vs. Flexibility

Vincent Gramoli

EPFL - March 7th, 2008

Multi-core Motivations

1. Transistor size allows multi-core

EPFL - March 7th, 2008

Multi-core Motivations

1. Transistor size allows multi-core

2. Processor speed is power-consuming

EPFL - March 7th, 2008

Multi-core Motivations

1. Transistor size allows multi-core

2. Processor speed is power-consuming

3. Limiting computation speed

EPFL - March 7th, 2008

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

EPFL - March 7th, 2008

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

EPFL - March 7th, 2008

Overview

1. Preliminaries

2. Making STM easy-to-use

3. Making STM flexible

4. Reconciling simplicity and flexibility

EPFL - March 7th, 2008

What is an interface?

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

[java.sun.com]

EPFL - March 7th, 2008

Interfacing STM

Application STM

beginTransaction()

endTransaction()

EPFL - March 7th, 2008

Interfacing STM

Application STM

beginTransaction()

endTransaction()

onAbort()

onCommit()

Abort handler

Commit handler

EPFL - March 7th, 2008

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?

EPFL - March 7th, 2008

Overview

1. Preliminaries

2. Making STM easy-to-use

3. Making STM flexible

4. Reconciling simplicity and flexibility

EPFL - March 7th, 2008

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?

EPFL - March 7th, 2008

Retries

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

Do (A) If (B) Retry

Implicit Requirement:

Implicit roll-back if B is true

Which previous actions should be canceled?

EPFL - March 7th, 2008

Exceptions

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

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

Implicit Requirement:

Implicit identification of the cause of the exception

How can we prevent this exception to raise again ?

EPFL - March 7th, 2008

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 ?

EPFL - March 7th, 2008

Overview

1. Preliminaries

2. Making STM easy-to-use

3. Making STM flexible

4. Reconciling simplicity and flexibility

EPFL - March 7th, 2008

Multi-level Interface

NooB Programmer needs Simplicity:

Desire of easy-of-use

Expert Programmer needs Flexbility:

Ability to tune the STM

EPFL - March 7th, 2008

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.

EPFL - March 7th, 2008

Dynamic STM 2

My Interface LinkedListNode

Factory

Class LinkedListNode

My Atomic Code

EPFL - March 7th, 2008

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

EPFL - March 7th, 2008

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.

EPFL - March 7th, 2008

Dynamic STM 2

My Interface LinkedListNode

Factory

Class LinkedListNode

My FactoryMy FactoryMy FactoryMy Factory

My Atomic Code

EPFL - March 7th, 2008

Dynamic STM 2

My Interface LinkedListNode

Factory

Class LinkedListNode

My FactoryMy FactoryMy FactoryMy Factory

My Atomic Code

My Contention Manager

EPFL - March 7th, 2008

Dynamic STM 2

My Interface LinkedListNode

Obstruction-freeFactory

Class LinkedListNode

My Atomic Code

EPFL - March 7th, 2008

Dynamic STM 2

My Interface LinkedListNode

ShadowFactory

Class LinkedListNode

My Atomic Code

EPFL - March 7th, 2008

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?

EPFL - March 7th, 2008

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

– Which transaction should abort the other?

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

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

…and so on

DSTM2

DSTM2

EPFL - March 7th, 2008

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]

EPFL - March 7th, 2008

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

EPFL - March 7th, 2008

Intel STM

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

Can we make it more flexible?

EPFL - March 7th, 2008

Overview

1. Preliminaries

2. Making STM easy-to-use

3. Making STM flexible

4. Reconciling simplicity and flexibility

EPFL - March 7th, 2008

Simplicity, Basic Interface

interface STMBasicallyUsable {

void beginTransaction()

void commitTransaction()

}

EPFL - March 7th, 2008

Simplicity, Basic Interface

Application STM

beginTransaction()

endTransaction()

EPFL - March 7th, 2008

Flexibility, Advanced Interface

interface STMCarefullyUsable extends Tunable {

void beginTransaction()

void commitTransaction()

}

EPFL - March 7th, 2008

Interfacing STMApplication STM

beginTransaction()

endTransaction()

onAbort()

onCommit()

Abort handler

Commit handler

resolveConflict()

Contentionmanager

store()load()

Memory

abort()

commit()

EPFL - March 7th, 2008

Flexibility, Advanced Interface

interface STMCarefullyUsable extends Tunable {

void beginTransaction()

void commitTransaction()

}

EPFL - March 7th, 2008

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

– Which transaction should abort the other?

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

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

• 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

EPFL - March 7th, 2008

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

– Which transaction should abort the other?

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

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

• 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

DSTM2

DSTM2

EPFL - March 7th, 2008

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

– Which transaction should abort the other?

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

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

• 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

DSTM2

DSTM2

Intel STM

EPFL - March 7th, 2008

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

EPFL - March 7th, 2008

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?