good programming in transactional memory game theory meets multicore architecture

Raphael Eidenbenz Roger Wattenhofer

Good Programming in Transactional MemoryGame Theory Meets Multicore Architecture

Raphael Eidenbenz, ETH Zurich. ISAAC 2009

Moore‘s Law

Clock speed flattening

sharply

Transistor count still

rising

Advent of multi-core

processors!


Multicore Architecture

Explicit locking• Parallel threads• Communication through shared memory• Developer: Explicit locking of shared

resources• Mark critical

sections• System: Guarantee exclusive execution

Transactional Memory


Contention ManagementWhich transaction shall I abort??


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 based


Is it a Game?

Yes• Players = programmers• Strategy space = placing of transactions• Their goal: fast execution• Social goal: maximize system throughput

„My thread is the fastest!“

Desired Behavior


incRingCounters(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!

R1

R3

t

R2

Rs

R1

R3

t

R2

Rs


Simulation Setup „Free-riding“ threads in DSTM2

• Coarse transaction granularity ( ¸ 20 accesses per transaction)

Collaborative threads• Granularity =1

16 threads on 16 cores do random updates on shared ordered list or red-black tree during 10 s.• 1 or 8 free-riders • High contention


SimulationResults

Karma Polka

Timestamp

throughput collaborators (updates/s) throughput collaborators (updates/s)

throughput collaborators (updates/s)

Randomized

throughput collaborators (updates/s)

thro

ughp

ut fr

ee-r

ider

s (up

date

s/s)

thro

ughp

ut fr

ee-r

ider

s (up

date

s/s)

thro

ughp

ut fr

ee-r

ider

s (up

date

s/s)

thro

ughp

ut fr

ee-r

ider

s (up

date

s/s)

Good Programming Incentives A CM is GPI compatible iff it

punishes unnecessary locking

and rewards partitioning.


Priority Based CM CM associates with each thread Ji a priority !i

Thread 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 CMThe oldest transaction has done the most work


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

What is wrong?


R1

R3

t

R2

Rs

R1

R3

t

R2

Rs

What is wrong?


Snatching up resources pushes priority

R1

R3

t

R2

Rs

R1

R3

t

R2

Rs

More Results


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

i. M increases a job’s priority on W-events .

ii. M increases relative priority on R-events.

iii. M schedules transactions gapless and increases priorities on C-events.

iv. 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.

Ti

Ti1 Ti2

Randomized CM Not priority based

„Choose random winner“

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

Partitioning:


Lemma 3: Randomized CM is GPI compatible.

Ti

Ti1 Ti2

Ti

Ti1 Ti2

Randomized CM Not priority based

„Choose random winner“

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

Partitioning:


Lemma 3: Randomized CM is GPI compatible.

Ti

Ti2


Conclusion & Open Problems

Further work:• Relax GPI compatibility• Trace effect in „real“ software

Thank you!

good programming in transactional memory game theory meets multicore architecture

Documents