1 / 18

The Xfork in the Road to Coordinated Sibling Transactions

This paper discusses the challenges of finding parallelism in the multi-core era and how transactional memory can help. It introduces the concept of coordinated sibling transactions and presents an API called xfork that enables programmers to easily create and manage parallel transactions. The performance benefits of this approach are demonstrated through benchmarks and comparisons to traditional STM.

bsunday
Download Presentation

The Xfork in the Road to Coordinated Sibling Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Xfork in the Road to Coordinated Sibling Transactions Hany E. Ramadan and Emmett Witchel University of Texas at Austin TRANSACT 2/15/2009

  2. TM solving the wrong problem ? • Finding parallelism is the key challenge of the multi-core era • Transactional memory makes creating critical regions easier • Transactional memory can also make.. • finding parallelism easier • ... but not with current model/API ! “Numerous types of processing are not well-served by [the flat transaction model’s simplicity] “ - Gray & Reuter 2

  3. How will TM find threads ? • Approach • Intratransaction parallelism • Benefits • Improve performance of individual transactions & utilize cores • Methodology • Revisit transaction model, API • Advice • “Intratransaction parallelism requires genuine support for nested transactions.” – Gray & Reuter

  4. Nested Transactions • Begin Tx (parent) • // work a • Begin Tx (nested) • // work b • End Tx (nested) • End Tx (parent) • Two types • Closed Nesting (commits into parent) • Open Nesting (commits into world) • Serial closed nesting • Simpler semantics (than open) • Small or no performance gain • Parallel closed nesting • Defined semantics for siblings • How much performance gain ?

  5. Forms of intra-transaction parallelism • Independent • Dependent • Speculative atomic Foo { } atomic Foo { } 5

  6. Programmer’s mental picture atomic Foo { } Foo OR FooTop FooBottom AND XOR # of leafs = maximum amount of intratransaction parallelism 6

  7. Coordination forms • OR (independent) • Independent siblings • No short circuit • AND (dependent) • All siblings must commit or none do • XOR (speculative) • Exactly one is allowed to commit • Once one sibling commits, all others made to abort • More forms conceivable

  8. Coordinated Sibling Model • Parallel closed nested transactions • Safety and semantics of closed nesting • Coordination forms express multiple paradigms • fork/join • distributed transactions • speculative execution • Sibling code returns Success/Fail • Commit/retry / abort decision made based on form, and status of siblings XOR ABT CMT ABT S S F 8

  9. xfork: API • xfork API shields programmer from the dirty work • Threading, coordination, aborting, speculation, etc. boolxfork (xforkForm, numForks, xforkProc, optionalData); enumxforkForm { AND, OR, XOR }; delegate xforkResultxforkProc (forkNum, optionalData); enumxforkResult { Success, Failure }; 9

  10. xfork: Example using (TransactionScopets = new TransactionScope()) { sstm.txStore.write (myAddr, “hello”); sstm.xfork( xforkForm.XOR, // form 2, // numForks new Delegate (parallelSearchProc), // xfProc myList); // data ts.Complete(); } xforkResultparallelSearchProc(intforkNum, object myList) { if (forkNum == 0) { FwdTraverse(myList) } else { ReverseTraverse(myList) } return xforkResult.Success; }

  11. Sibling STM (SSTM): Architecture • System.Transactions provides database-derived framework • DB terminology: • TM: Transaction Manager (executes 2 phase commit protocol) • RM: Resource Manager (holds transactional data / votes in 2pc) • ‘Enlisting’: when RM first meets TM. • Sibling Executive (SibEx) (RM) • Implements xfork semantics • TxStore (RM) • Conventional STM

  12. SSTM: SibEx • Schedule work for each fork on some thread Use existing thread-pool • Create sibling nested transactions • Invoking user-procedure for each fork • Enforce semantics of each sibling form May involve finding transaction outcome (OR-form), or enlisting and voting on outcome (AND/XOR-form) • Stalling the parent appropriately 12

  13. SSTM: TxStore • Extends TL2 to support nesting • Key change: per-object version-number (for write set) • Additional synchronization to supported parallel access • Extend System.Transactions to support nesting • Thread-local transactional context extended with “parents” list • Low-level API, based on System.Object/ICloneable • object TxStore.Read(int address); • void TxStore.Write(int address, object obj);

  14. SSTM: Prototype • System configuration • Intel Core2 Quad CPU running at 2.66 Ghz • Microsoft .NET v2 Framework, MS Windows Vista • SSTM: 2,345 lines of C# code • Benchmarks (~600 loc) • SearchList: • Search linked list in parallel • Transfer • Debit/credit of bank accounts using two lists • Compare SSTM to SSTM without xfork • Measure speedup, from 1 to 4 forks 14

  15. SearchList benchmark • Four-fork version also searches from middle of list

  16. Transfer benchmark • Higher overhead due to AND-form coordination

  17. Related Work • Nested Transactions • Formalized by [Moss81], [Beeri83] • Used in Argus[Liskov88], Camelot [Eppinger91] • TM Nesting • HTM [Moravan06, McDonald06] • STM [Ni07, Harris07, Moss05] • Parallelism • Fortress[Allen07], XCilk[Agrawal08] • Parallel for-loops, etc. in OpenTM[Baek07] • Composition constructs (e.g. orElse) [Harris05] 17

  18. Conclusion • Intratransaction parallelism • Makes TM even more relevant to the challenges of multi-core • Coordinated siblings • Transaction model that suits this type of processing • xfork • Makes coordinated siblings easy to use Will intratransaction parallelism become a commodity ?

More Related