Raphael Eidenbenz - PowerPoint Presentation

Slide1

Raphael Eidenbenz Roger Wattenhofer

Good Programming in Transactional Memory

Game Theory Meets

Multicore

ArchitectureSlide2

Raphael Eidenbenz, ETH Zurich. ISAAC 2009Moore‘s Law

Clock speed flattening sharply

Transistor count still rising

Advent of multi-core processors!Slide3

Raphael Eidenbenz, ETH Zurich. ISAAC 2009Multicore ArchitectureExplicit lockingParallel threadsCommunication through shared memoryDeveloper: Explicit locking of shared resources

Mark critical sectionsSystem: Guarantee exclusive execution

Transactional MemorySlide4

Raphael Eidenbenz, ETH Zurich. ISAAC 2009Contention Management

Which transaction shall I abort??Slide5

Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Contention Managers

Timestamp

Oldest transaction wins

Polite

Exponential backoff

Karma

Transaction with most locked resources wins

Priority is carried over to next attempt when aborted

Polka

Karma with exponential backoff

Randomized

Pick a random winner

priority based

non-priority basedSlide6

Raphael Eidenbenz, ETH Zurich. ISAAC 2009Is it a Game?YesPlayers = programmersStrategy space = placing of transactionsTheir goal: fast execution

Social goal: maximize system throughput

„My thread is the fastest!“Slide7

Desired BehaviorRaphael Eidenbenz, ETH Zurich. ISAAC 2009incRingCounters(Node start){

var cur = start; transaction{ while(cur.next!=start){

cur.doSomething();

cur = cur.next; }

}

}

incRingCountersGP(Node start){

var cur = start;

while(cur.next!=start){

transaction{

cur.doSomething();

}

cur = cur.next;

}} Transactions as short as possible!

R

1R3

t

R

2

R

s

R

1

R

3

t

R

2

R

sSlide8

Raphael Eidenbenz, ETH Zurich. ISAAC 2009Simulation Setup„Free-riding“ threads in DSTM2 Coarse transaction granularity ( ¸ 20 accesses per transaction)

Collaborative threadsGranularity =116 threads on 16 cores do random updates on shared ordered list or red-black tree during 10 s.

1 or 8 free-riders

High contentionSlide9

Raphael Eidenbenz, ETH Zurich. ISAAC 2009SimulationResults

Karma

Polka

Timestamp

throughput collaborators (updates/s)

throughput collaborators (updates/s)

throughput collaborators (updates/s)

Randomized

throughput collaborators (updates/s)

throughput free-riders (updates/s)

throughput free-riders (updates/s)

throughput free-riders (updates/s)

throughput free-riders (updates/s)Slide10

Good Programming IncentivesA CM is GPI compatible iff it punishes unnecessary locking and rewards partitioning.Raphael Eidenbenz, ETH Zurich. ISAAC 2009Slide11

Priority Based CMCM associates with each thread Ji a priority !iThread with highest priority wins conflicts

Rationale: „Don‘t discard the transaction who has done most“

Underlying assumption: Priority measures the amount of work done

E.g. Timestamp CM

The oldest transaction has done the most work

Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Theorem:

Polite, Greedy, Karma, Timestamp and Polka are not GPI compatible.Slide12

What is wrong?Raphael Eidenbenz, ETH Zurich. ISAAC 2009

R

1

R

3

t

R

2

R

s

R

1

R

3

t

R

2

R

sSlide13

What is wrong?

Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Snatching up resources pushes priority

R

1

R

3

t

R

2

R

s

R

1

R

3

t

R

2

R

sSlide14

More ResultsRaphael Eidenbenz, ETH Zurich. ISAAC 2009

Theorem 3:

Any priority-accumulating CM M is not GPI compatible if one of the following holds:

M increases a job’s priority on

W

-events .

M increases relative priority on

R

-events.

M schedules transactions gapless and increases priorities on

C

-events.

M restarts aborted transactions immediately and increases priorities on

A

-events

Theorem 2

: Quasi priority accumulating CMs are not GPI compatible.Theorem 4: Any priority-accumulating CM that is based only on time is GPI compatible.Slide15

Ti

T

i1

T

i2

Randomized CM

Not priority based

„Choose random winner“

Proof Intuition

Unnecessary Locks: Stupid because only risk conflict (no priority gain)

Partitioning:

Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Lemma 3

:

Randomized CM is GPI compatible.

T

i

T

i1

T

i2Slide16

Ti

T

i1

T

i2

Randomized CM

Not priority based

„Choose random winner“

Proof Intuition

Unnecessary Locks: Stupid because only risk conflict (no priority gain)

Partitioning:

Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Lemma 3

:

Randomized CM is GPI compatible.

T

i

T

i2Slide17

Raphael Eidenbenz, ETH Zurich. ISAAC 2009Conclusion & Open ProblemsFurther work:Relax GPI compatibilityTrace effect in „real“ software

Thank you!