1. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 1 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

2. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 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. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 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. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 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. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 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. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 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. U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science 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