Transactional abstractions: beyond atomic update

1
Transactional abstractionsbeyond 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
(No Transcript)
7
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)