Presentation is loading. Please wait.

Presentation is loading. Please wait.

R 1 Transactional abstractions: beyond atomic update Tim Harris r.

Similar presentations


Presentation on theme: "R 1 Transactional abstractions: beyond atomic update Tim Harris r."— Presentation transcript:

1 r 1 Transactional abstractions: beyond atomic update Tim Harris r

2 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 r 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 r 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 it see when it dereferences foo..? what if someone catches the exception and looks inside..?

5 r 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 r 6

7 r 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)


Download ppt "R 1 Transactional abstractions: beyond atomic update Tim Harris r."

Similar presentations


Ads by Google