An Automated Framework for Decomposing Memory Transac?ons to - PowerPoint PPT Presentation

An ¡Automated ¡Framework ¡for ¡Decomposing ¡ Memory ¡Transac?ons ¡to ¡Exploit ¡Par?al ¡Rollback ¡ Aditya ¡Dhoke, ¡Roberto ¡Palmieri, ¡and ¡Binoy ¡Ravindran ¡ ¡ Systems ¡So)ware ¡Research ¡Group ¡ Virginia ¡Tech ¡ IPDPS ¡2015 ¡

Lock-based concurrency control has serious drawbacks • Fine-­‑grained ¡locking ¡ • Coarse-­‑grained ¡locking ¡ – Excellent ¡performance, ¡but ¡ – Simple, ¡but ¡no ¡concurrency ¡ poor ¡programmability ¡ – Hard ¡to ¡compose ¡ Time Coarse-grained locking Fine-grained locking Threads 2

Transac?onal ¡memory ¡promises ¡to ¡ alleviate ¡these ¡difficul?es ¡ • Similar ¡to ¡ACID ¡transac?ons ¡ • Easier ¡to ¡program ¡ • Decent ¡performance ¡ • Composable ¡ Time Coarse-grained locking STM Fine-grained locking (PPoPP, ¡‘06) ¡ Herlihy ¡and ¡Moss, ¡‘93 ¡ Threads 3

Transac?ons ¡can ¡be ¡nested ¡for ¡beVer ¡ composability, ¡performance, ¡… ¡ @Atomic{ ¡ ¡ ¡ ¡@Atomic{ ¡ Sub-­‑transac?on ¡ Sub-­‑transac?on ¡ ¡ ¡ ¡ ¡ ¡ ¡Account ¡src ¡= ¡getAccount(a_src); ¡ ¡ ¡ ¡ ¡ ¡ ¡int ¡b_src ¡= ¡getBalance(src); ¡ root-­‑transac?on ¡ ¡ ¡ ¡ ¡ ¡ ¡setBalance(b_src ¡-­‑ ¡X); ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡Account ¡dst ¡= ¡getAccount(a_dst); ¡ ¡ ¡ ¡ ¡ ¡ ¡int ¡b_dst ¡= ¡getBalance(dst); ¡ ¡ ¡ ¡ ¡ ¡ ¡setBalance(b_dst ¡+ ¡X); ¡ ¡ ¡ ¡} ¡ } ¡ ¡ (Moss ¡and ¡Hosking, ¡'06) ¡ 4

Several ¡nes?ng ¡models ¡exist ¡ • Flat ¡nes?ng ¡ • Closed ¡nes?ng ¡ • Open ¡nes?ng ¡ ¡ 5

Flat ¡nes?ng ¡is ¡no ¡nes?ng ¡ Flat inner transactions accessing a shared object T 1 successfully commits T 1 commit T 2 T 2 must abort while T 1 is still executing T 2 may proceed after T 1 commits Time ¡ 6

Closed ¡nes?ng ¡may ¡improve ¡ performance ¡ Closed inner transactions accessing a shared object T 1 successfully commits T 1 commit T 2 T 2 's inner transaction must abort while T 1 is still executing T 2 's inner transaction may proceed after T 1 commits Time ¡ 7

Open ¡nes?ng ¡may ¡perform ¡even ¡beVer, ¡ ¡ ¡ ¡ ¡ ¡ ¡ at ¡the ¡expense ¡of ¡physical ¡serializability ¡ Open inner transactions accessing a shared object T 1 's inner transaction commits and releases its isolation T 1 successfully commits T 1 T 2 successfully commits T 2 T 2 's inner transaction only has to abort T 2 's inner transaction may while T 1 's inner transaction is executing proceed as soon as T 1 's inner transaction commits Time ¡ 8

Open ¡nes?ng ¡reduces ¡false ¡conflicts ¡ and ¡yields ¡ abstract ¡serializability ¡ • T1 ¡and ¡T2 ¡can ¡execute ¡and ¡commit ¡ Shared set s ; concurrent ly iff x ≠ y ≠ z Transaction T1: Transaction T2: • But ¡T1 ¡and ¡T2 ¡traverse ¡same ¡physical ¡ Atomic { Atomic { s .insert( x ); s .insert( z ); structure ¡=> ¡physical ¡conflict ¡ s .insert( y ); } } – False ¡conflict ¡ Abstract lock Abstract lock Abstract lock a b x c y d z Transaction T1: Atomic { time BeginNest_1 Transaction T2: s .insert( x ); Atomic { CommitNest_1 s .insert( z ); BeginNest_2 } s .insert( y ); CommitNest_2 } Upon ¡ CommitNest_1 ¡(and ¡ CommitNest_2 ), ¡ read-­‑set ¡is ¡released ¡and ¡abstract ¡locks ¡acquired ¡ ¡ No ¡conflicts ¡on ¡ a ¡, b , ¡ c , ¡ d , ¡but ¡only ¡on ¡ x , ¡ y ¡ 9

Paper’s ¡focus ¡is ¡on ¡closed ¡nes?ng ¡ • If ¡there ¡is ¡a ¡conflict ¡on ¡ // ¡ Matrices: ¡m 1 , ¡m 2 , ¡m 3 ¡ ¡ accessing ¡m 3 : ¡ @Atomic{ ¡// ¡T_flat ¡ – flat ¡nes?ng ¡will ¡restart ¡ from ¡ T_flat ¡ ¡m1 ¡= ¡getObj(m1_Obj); ¡ – closed ¡nes?ng ¡will ¡restart ¡ ¡m2 ¡= ¡getObj(m2_Obj); ¡ T_closed, ¡ saving ¡ ¡m3 ¡= ¡getObj(m3_Obj); ¡ opera?ons ¡on ¡m 1 ¡and ¡m 2 ¡ ¡intm ¡= ¡add(m1,m2); ¡ • Root’s ¡commit ¡will ¡likely ¡ ¡ ¡ ¡ ¡@Atomic{ ¡// ¡T_closed ¡ succeed ¡ ¡result ¡= ¡add(intm,m3); ¡ • Gains ¡can ¡be ¡significant ¡in ¡ ¡ ¡ ¡ ¡ ¡ } ¡ distributed ¡systems ¡ } ¡ – Object ¡lookup ¡involves ¡ network ¡communica?ons ¡ 10

But ¡sub-­‑transac?ons ¡have ¡to ¡be ¡ programmer-­‑defined ¡ • Step ¡backwards! ¡ – Reduces ¡TM’s ¡high ¡programmability ¡ • Closed ¡nes?ng ¡enables ¡par?al ¡abort ¡in ¡TM, ¡ poten?ally ¡increasing ¡performance ¡ • Is ¡it ¡possible ¡to ¡automate ¡the ¡defini?ons ¡of ¡ closed ¡nested ¡transac?ons? ¡ – Increases ¡TM ¡performance, ¡retaining ¡high ¡ programmability ¡ 11

Contribu?on ¡is ¡ACN ¡ • Automa?c ¡framework ¡for ¡composing ¡closed ¡ nested ¡transac?ons ¡ – Completely ¡programmer-­‑transparent ¡ – Heuris?c ¡algorithm ¡ • Dynamic ¡framework ¡ – Op?mize ¡(closed-­‑nested) ¡transac?on ¡defini?on ¡at ¡ run-­‑?me ¡to ¡adapt ¡to ¡transac?onal ¡conten?ons ¡ and ¡workload ¡fluctua?ons ¡ – (Non-­‑trivial ¡to ¡do ¡so ¡manually) ¡ 12

Mul?ple ¡factors ¡affect ¡performance ¡of ¡ closed-­‑nested ¡transac?ons ¡ • Nes?ng ¡granularity ¡ @Atomic{ ¡ – # ¡opera?ons ¡performed ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1 ¡= ¡getObject(branchId1); ¡ by ¡a ¡sub-­‑transac?on ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2 ¡= ¡getObject(branchId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1.withdraw(amt1); ¡ • Conten?on ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2.deposit(amt2); ¡ ¡ ¡ ¡ ¡ ¡ ¡account1 ¡= ¡getObject(accountId1); ¡ – Shared ¡objects ¡accessed ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡account2 ¡= ¡getObject(accountId2); ¡ by ¡a ¡sub-­‑transac?on ¡ ¡ ¡ ¡ ¡ ¡ ¡account1.withdraw(amt1); ¡ ¡ ¡ ¡ ¡ ¡ ¡account2.deposit(amt2); ¡ • Lexical ¡posi?on ¡ ¡ } ¡ Bank ¡benchmark’s ¡transac=on ¡ – Each ¡sub-­‑transac?on’s ¡ (flat ¡nes=ng) ¡ posi?on ¡in ¡root ¡ 13

Granularity ¡impacts ¡ ¡ Finest ¡granularity: ¡ performance ¡ wrap ¡each ¡opera?on ¡ as ¡a ¡sub-­‑transac?on ¡ Coarse ¡granularity: ¡ @Atomic{ ¡ wrap ¡all ¡opera?ons ¡as ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1 ¡= ¡getObject(branchId1); ¡ one ¡sub-­‑transac?on ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡@Atomic{ ¡ @Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2 ¡= ¡getObject(branchId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1 ¡= ¡getObject(branchId1); ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2 ¡= ¡getObject(branchId2); ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1.withdraw(amt1); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1.withdraw(amt1); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2.deposit(amt2); ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡ ¡ ¡ ¡account1 ¡= ¡getObject(accountId1); ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡account2 ¡= ¡getObject(accountId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2.deposit(amt2); ¡ ¡ ¡ ¡ ¡ ¡ ¡account1.withdraw(amt1); ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡ ¡ ¡ ¡account2.deposit(amt2); ¡ … ¡ } ¡ INEFFECTIVE! ¡ } ¡ NO ¡PARTIAL ¡ABORT! ¡ 14

Grouping ¡objects ¡with ¡similar ¡access ¡ probability ¡affects ¡performance ¡ System ¡hot ¡spots: ¡ branch1, ¡branch2 ¡ System ¡hot ¡spots: ¡ branch1, ¡branch2 ¡ Objects ¡less ¡contended: ¡ account1, ¡account2 ¡ Objects ¡less ¡contended: ¡ account1, ¡account2 ¡ ¡ ¡ @Atomic{ ¡ @Atomic{ ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1 ¡= ¡getObject(branchId1); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch1 ¡= ¡getObject(branchId1); ¡ ¡ ¡ ¡ ¡ ¡ ¡account1 ¡= ¡getObject(accountId1); ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2 ¡= ¡getObject(branchId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡… ¡ ¡ ¡ ¡ ¡ ¡ ¡… ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡@Atomic{ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡branch2 ¡= ¡getObject(branchId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡account1 ¡= ¡getObject(accountId1); ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡account2 ¡= ¡getObject(accountId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡account2 ¡= ¡getObject(accountId2); ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡… ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡… ¡ ¡ ¡ ¡ ¡} ¡ ¡ ¡ ¡ ¡} ¡ INEFFECTIVE! ¡ EFFECTIVE! ¡ } ¡ } ¡ 15