1 / 7

Three Challenges for Transactional Computing

Three Challenges for Transactional Computing. J. Eliot B. Moss Associate Professor, University of Massachusetts moss@cs.umass.edu Joint position with Tony Hosking (Purdue) Students: Athul Acharya, Phil McGachey, and Trek Palmer Supported by Intel & NSF Grant CCF-0540862.

ted
Download Presentation

Three Challenges for Transactional Computing

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. Three Challenges forTransactional Computing J. Eliot B. Moss Associate Professor, University of Massachusetts moss@cs.umass.edu Joint position with Tony Hosking (Purdue) Students: Athul Acharya, Phil McGachey, and Trek Palmer Supported by Intel & NSF Grant CCF-0540862

  2. Extended Transaction Semantics • Motivation 1: Concurrency • We assume that we need something like open nesting to obtain desired performance • Concern 1: Can real programmers code open nesting properly? • Our experience: At the class level, inverses are not that hard, but abstract concurrency control may be tricky • Challenge: Derive abstract concurrency control automatically, or at least check it

  3. Extended Transaction Semantics (2) • A possible approach: • Open atomic class states its abstraction • Methods give pre- and post-conditions • Tools derive cc, and check pre/post-conditions • Concern 2: Can we guarantee a safe implementation (no deadlocks, etc.)? • Challenge: Devise a suitable static or dynamic check, or language restriction, that prevents deadlock of undos, etc.

  4. Extended Transaction Semantics (3) • Motivation 2: Escaping strict serializability • Concern: Dangerous arbitrary loophole • Challenge: Allow appropriate description, and checking, of desired (non)constraints w.r.t. permanence of effects and/or concurrency control conflicts • Challenge: Allow suitable control of order, where desired

  5. Extended Transaction Semantics (4) • Concern: Smooth integration with OS • Challenge: Retooling libraries given presence of transactions • Challenge: Revising OS and its API to provide/support transactions

  6. Generating Concurrency • Concern: Java-style threads are inadequate • Challenge: Get more bulk parallelism from generalized loops over collections • Thought: Look more to database-style query languages, since they inherently deal in bulk, generating more parallelism • But we need more: fork-join? futures? • Challenge: Real performance must deal with scheduling concerns, e.g., locality & affinity

  7. Hardware Model • Concern: Ultimate acceptance demands performance that requires h/w support • Challenge: Finding a h/w model that does not over-commit in its approach: Provides speedup while remaining flexible • Challenge: Allowing vendor h/w diversity with minimal need for s/w variation • Suggestion: More like TLBs supporting virtual memory than like IEEE floating point, but maybe more in s/w

More Related