![Page 1: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/1.jpg)
Raphael Eidenbenz Roger Wattenhofer
Good Programming in Transactional MemoryGame Theory Meets Multicore Architecture
![Page 2: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/2.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Moore‘s Law
Clock speed flattening
sharply
Transistor count still
rising
Advent of multi-core
processors!
![Page 3: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/3.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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
![Page 4: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/4.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Contention ManagementWhich transaction shall I abort??
![Page 5: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/5.jpg)
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 based
![Page 6: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/6.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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!“
![Page 7: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/7.jpg)
Desired Behavior
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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
![Page 8: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/8.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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
![Page 9: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/9.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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)
![Page 10: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/10.jpg)
Good Programming Incentives A CM is GPI compatible iff it
punishes unnecessary locking
and rewards partitioning.
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
![Page 11: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/11.jpg)
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
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Theorem: Polite, Greedy, Karma, Timestamp and Polka are not GPI compatible.
![Page 12: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/12.jpg)
What is wrong?
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
R1
R3
t
R2
Rs
R1
R3
t
R2
Rs
![Page 13: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/13.jpg)
What is wrong?
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Snatching up resources pushes priority
R1
R3
t
R2
Rs
R1
R3
t
R2
Rs
![Page 14: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/14.jpg)
More Results
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
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.
![Page 15: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/15.jpg)
Ti
Ti1 Ti2
Randomized CM Not priority based
„Choose random winner“
Proof IntuitionUnnecessary Locks: Stupid because only risk conflict (no priority gain)
Partitioning:
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Lemma 3: Randomized CM is GPI compatible.
Ti
Ti1 Ti2
![Page 16: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/16.jpg)
Ti
Ti1 Ti2
Randomized CM Not priority based
„Choose random winner“
Proof IntuitionUnnecessary Locks: Stupid because only risk conflict (no priority gain)
Partitioning:
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Lemma 3: Randomized CM is GPI compatible.
Ti
Ti2
![Page 17: Good Programming in Transactional Memory Game Theory Meets Multicore Architecture](https://reader035.vdocuments.mx/reader035/viewer/2022062811/56816206550346895dd22bfb/html5/thumbnails/17.jpg)
Raphael Eidenbenz, ETH Zurich. ISAAC 2009
Conclusion & Open Problems
Further work:• Relax GPI compatibility• Trace effect in „real“ software
Thank you!