1. Gargamel: A Conflict-Aware Contention Resolution Policy for STM Pierpaolo Cincilla, Marc Shapiro, Sébastien Monnet

2. 2 High contention => Repetitive aborts, poor performance ● Transactions in a TM execute speculatively: ● Commit if no conflicts ● Abort otherwise Low contention => Good performance

3. 3 Client Load balancer Black box DB Concurrency control, contention => Distributed configurations scale poorly ● Single thread DBs perform well ● Scale => parallel, distributed

4. 4 Current approaches: Acts after conflict detection Do not avoid wasted work => ● TM schedulers Avoid conflicts to appear } Avoid wasted work => ● Contention ● Manager }

5. 5 Current approaches : Contention Manager ● Polite ● Karma ● Greedy ● Serializer Acts after conflict detection } Do not avoid wasted work => ● TM schedulers ● Polite ● Karma ● Greedy ● Serializer Avoid conflicts to appear } Avoid wasted work =>

6. 6 Current approaches ● Memory partition => No global transactions ● Centralise writes ● Read-dominated workloads ● Weaken semantics (key-value store, NoSQL) ● Problematic for applications => SI }

7. 7 Intuition Throughput-optimal = ● No concurrent conflicting ● transactions => no aborts ● 1 site = 1 scheduler + n workers threads – Conflicting => sequential ''chain'' – Non conflicting => parallel Conflict estimation

8. 8 Intuition Throughput-optimal = ● No concurrent conflicting ● transactions => no aborts ● 1 site = 1 scheduler/load balancer + n workers – Conflicting => sequential ''chain'' – Non conflicting => parallel Conflict estimation

9. 9 The Gargamel scheduling algorithm 1 Scheduler clients 1 Conflict ? 2 1 1 1 2 34567823 1234 910 23444 234 1234 12 12 123 12345 4 1

10. Architecture Scheduler 2 Threads Fault tolerance, latency, load => several sites Clients Site 1 Scheduler 1 Threads Site 2 Transaction transmission + agreement Clients

11. 11 2 The Gargamel scheduling algorithm (2) Scheduler 1 clients Scheduler 2 clients 1 13 2 23 24 2 4 4 5 5 Execution Canc elled 4 5 56 6 AGREEMENT Transactions Agree in the oucome of bet Bet 7 1 Killed 1 2 3 34 4 78 78 89 89 5 56 6 7 9 9

12. 12 Simulation results Measure: ● Resource usage – Number of running threads in ressources bounded systems ● Price of concurrency – Cancel/kill rate with respect to number of sites, message delay ● Simulation engine ● Simulated workload : TPC-C – Vary = number of sites, distance between sites (latency within sites =0) – Constant : workload

13. 13 Resource usage (TPC-C) ● No overloaded threads Gargamel Passive

14. 14 Resource usage (TPC-C) ● No overloaded threads Gargamel Passive

15. 15 Throughput (TPC-C) ● Better throughput Gargamel Passive

16. 16 Throughput (TPC-C) ● Better throughput Gargamel Passive

17. 17 Penalisation (TPC-C) ● Better response time Gargamel Passive

18. 18 100ms Price of concurrency (TPC-C) ● Good speedup even at high latency (up to 100ms) ● Kills are rare 300ms 500ms Cancelled (before execution) Kill (after termination) Kill (during execution) Transactions executed Optimum

19. 19 Price of concurrency (TPC-E) ''Trade Result'' transaction is the bottleneck – Conflict parameter not available to oracle – TODO: add parameter to TPC-E 10ms 100ms optimum Transactions executed Cancelled (before execution) Kill (after termination)

20. 20 Impact of message delay Higher kill/annullation rate in TPC-E ● Different incoming rate of bottleneck ● transaction (TPC-C : 88%, TPC-E 10%) Cancel Kil l

21. 21 Contributions ● Conflict estimation = w/w conflicts = static analysis ● Chains = structured scheduler queues ● Load balancing + concurrency control = schedules ● Preventively parallelize unconflicting chains

22. 22 Lesson learned ● Measure of optimum = single site, compare multiple site ● No concurrent conflicting transactions => no aborts ● Simulation result = benefits proportional to oracle accuracy and incoming rate ● Schedules as optimal as estimator is

23. 23 Lesson learned ● Measure of optimum = single site, compare multiple site ● No concurrent conflicting transactions => no aborts ● Simulation result = benefits proportional to oracle accuracy and incoming rate ● Schedules as optimal as estimator is ● Trade-off black box STM / agreement off critical path ● Share-nothing => no resource contention

24. 24 Lesson learned ● Measure of optimum = single site, compare multiple site ● No concurrent conflicting transactions => no aborts ● Simulation result = benefits proportional to oracle accuracy and incoming rate ● Schedules as optimal as estimator is ● Trade-off black box DB / agreement off critical path ● Share-nothing => no resource contention

25. 25 Future Work ● Simulate Gargamel VS Tashkent+, and LARD (1m) ● Implementation + evaluation with real workloads (10m) ● Partial replication (similar to Tashkent+, comes almost for free) (1m) ● False negative => handle DB aborts (1m) ● Machine learning oracle (1m) ● Thesis (6m)