1 / 7

Transactional abstractions: beyond atomic update

Transactional abstractions: beyond atomic update. Tim Harris. r. Introduction. Suppose we have efficient support for atomic multi-word updates Including contention-management & fairness issues etc

koko
Download Presentation

Transactional abstractions: beyond atomic update

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. Transactional abstractions:beyond atomic update Tim Harris r

  2. Introduction • Suppose we have efficient support for atomic multi-word updates • Including contention-management & fairness issues etc • Whether using a pure hardware implementation, a hybrid hardware/software one, or a pure software approach • What problems remain in using this to implement pervasive atomic blocks? • What expressiveness problems remain with using pervasive atomic blocks as a programming abstraction? i.e. spanning in-memory and external data, and expressive enough to replace rather than augment mutexes and condition variables in common uses

  3. Blocking • Blocking & wake-up using atomic blocks atomic { if (full == false) retry; full = false; return item; } • Controlling blocking in called code try { return buffer.get_item(); } catch_retry { return null; } • Blocking for conditions involving multiple threads or conditions involving external events – chords seem a much better fit for this

  4. Interaction and safety • Interaction with external resources supporting transactions: 2PC (ignoring blocking & wake-up…) • Notice the problems of doing this in a safe language atomic { foo = new XYZ(); external_operation(foo); } • Also if the programmer can trigger roll-back (which the TM must then support…) atomic { foo = new XYZ(); throw new Exception(foo); } if this can ‘step outside’ the transaction in order to (e.g.) interact with a database, then what will itsee when it dereferences foo..? what if someone catches the exception and looks inside..?

  5. Transactional interface • Per-CPU transactions vs per-thread programming abstractions • Physically-addressed vs virtually-addressed transactional memory implementations • Cross-protection-domain control-flow transfers (exception and interrupt delivery, system calls) • Use of transactions at multiple levels (Nested scopes or full nested transaction? Possibly involving application thread, managed-runtime, OS) • Interaction with GC and other managed-runtime services • Ability to exploit knowledge of transaction-local and thread-local data (via type system / inference)

  6. Papers • Haskell system http://www.haskell.org/ghc/ • Unmanaged STM under a BSD-style license from http://www.cl.cam.ac.uk/netos/lock-free • Papers: • ‘Language support for lightweight transactions’ at OOPSLA 2003 (with Keir Fraser) • ‘Exceptions and side-effects in atomic blocks’ at CSJP 2004 • ‘Concurrent programming without locks’ under submission to TOCS (with Keir Fraser) • ‘Revocable locks for lock-free programming’ and ‘Composable memory transactions’ both at PPoPP 2005 (with Maurice Herlihy, Simon Marlow, Simon Peyton-Jones)

More Related