The Transactional Manifesto

							The Transactional Manifesto

       Maurice Herlihy
      Microsoft Research
     and Brown University
   From the New York Times …
SAN FRANCISCO, May 7. 2004 - Intel said
on Friday that it was scrapping its development
of two microprocessors, a move that is a shift
in the company's business strategy….




25-Nov-11            PLDI 2005                2
            Moore’s Law             Transistor
                                    count still
                                      rising

                                   Clock speed
                                    flattening
                                     sharply




                           (hat tip: Simon Peyton-Jones)




25-Nov-11      PLDI 2005                         3
            Multicore Architetures
  • “Intel's first dual-core processor will be
    available April 18 from PC vendors ….”
  • “AMD will launch a dual-core version of its
    Opteron server processor at an event in
    New York on April 21.” [PC World]
  • “Sun’s UltraSparc IV processor combines 2
    UltraSparc III cores on one slice of silicon
    ….” [xbitlabs]

25-Nov-11             PLDI 2005                4
            Why do we care?
  • Time no longer cures software bloat
  • When you double your path length
       – You can’t just wait 6 months
       – Your software must somehow exploit
         twice as much concurrency




25-Nov-11              PLDI 2005              5
                 The Problem
  • Cannot exploit cheap threads
  • Today’s Software
       – Non-scalable methodologies
  • Today’s Hardware
       – Poor support for scalable
         synchronization


25-Nov-11               PLDI 2005     6
            Locking




25-Nov-11    PLDI 2005   7
            Coarse-Grained Locking



      Easily made correct …
      But not scalable.




25-Nov-11            PLDI 2005       8
            Fine-Grained Locking




 Here comes trouble …




25-Nov-11           PLDI 2005      9
     Why Locking Doesn’t Scale
  • Not Robust
  • Relies on conventions
  • Hard to Use
       – Conservative
       – Deadlocks
       – Lost wake-ups
  • Not Composable
25-Nov-11                PLDI 2005   10
             Locks are not Robust
If a thread holding
a lock is delayed …




                                  No one else can
                                  make progress
 25-Nov-11            PLDI 2005              11
     Why Locking Doesn’t Scale
  • Not Robust
  • Relies on conventions
  • Hard to Use
       – Conservative
       – Deadlocks
       – Lost wake-ups
  • Not Composable
25-Nov-11                PLDI 2005   12
     Locking Relies on Conventions

  • Relation between
       – Lock bit and object bits     Actual comment
                                     from Linux Kernel
       – Exists only in programmer’s mind Bradley Kuszmaul)
                                      (hat tip:


   /*
    * When a locked buffer is visible to the I/O layer
    * BH_Launder is set. This means before unlocking
    * we must clear BH_Launder,mb() on alpha and then
    * clear BH_Lock, so no reader can see BH_Launder set
    * on an unlocked buffer and then risk to deadlock.
    */



25-Nov-11                    PLDI 2005                     13
     Why Locking Doesn’t Scale
  • Not Robust
  • Relies on conventions
  • Hard to Use
       – Conservative
       – Deadlocks
       – Lost wake-ups
  • Not Composable
25-Nov-11                PLDI 2005   14
            Sadistic Homework

              Double-ended queue   enq(y)
 enq(x)




              No interference if
              ends “far enough”
                    apart

25-Nov-11           PLDI 2005           15
            Sadistic Homework

              Double-ended queue    enq(y)
 enq(x)




              Interference OK if
              ends “close enough”
                   together

25-Nov-11           PLDI 2005            16
            Sadistic Homework

              Double-ended queue   deq()
  deq()

                     

                  Make sure
                  suspended
              dequeuers awake as
                    needed
25-Nov-11           PLDI 2005          17
                 You Try It …
  • One lock?
       – Too Conservative
  • Locks at each end?
       – Deadlock, too complicated, etc
  • Waking blocked dequeuers?
       – Harder that it looks


25-Nov-11               PLDI 2005         18
            Actual Solution
  • Clean solution would be a publishable
    result
  • [Michael & Scott, PODC 96]
  • What good is a methodology where
    solutions to such elementary problems
    are hard enough to be publishable?


25-Nov-11          PLDI 2005            19
  In Search of the Lost Wake-Up

  • Waiting thread doesn’t realize when
    to wake up
  • It’s a real problem in big systems
       – “Calling pthread_cond_signal() or
         pthread_cond_broadcast() when the thread
         does not hold the mutex lock associated with
         the condition can lead to lost wake-up bugs.”
                          from Google™ search for “lost wake-up”


25-Nov-11                  PLDI 2005                          20
     Why Locking Doesn’t Scale
  • Not Robust
  • Relies on conventions
  • Hard to Use
       – Conservative
       – Deadlocks
       – Lost wake-ups
  • Not Composable
25-Nov-11                PLDI 2005   21
             Locks do not compose
       Hash Table               T1
                           lock T1
                                         Must lock T1
       add(T1, item)                     before adding
                            item
                                         item

Move from T1 to T2

                              T1
                         lock T1         lock T2
                                         lock T2
      delete(T1, item)                             Must lock T2
      add(T2, item)                                before deleting
                          item            item
                                                   from T1


     Exposing lock internals breaks abstraction
 25-Nov-11                   PLDI 2005                      22
            Monitor Wait and Signal


                                     Empty
               zzz
               Yes!
                                     buffer

                          If buffer is empty,
                           wait for item to show up

25-Nov-11             PLDI 2005                23
  Wait and Signal do not Compose




   empty
Wait for either?

                               empty
                                zzz…

25-Nov-11          PLDI 2005           24
  The Transactional Manifesto
  • What we do now is inadequate to
    meet the multicore challenge
  • Research Agenda
       – Replace locking with a transactional API
       – Design languages to support this model
       – Implement the run-time to be fast
         enough

25-Nov-11               PLDI 2005               25
            Related Work: Software
  • DSTM [PODC 03]
       – Sun Microsystems, Java library
  • FSTM, OSTM [OOPSLA 03]
       – Cambridge University, Java extension
  • STM Haskell [PPoPP 05 that’s tomorrow!]
       – Microsoft Research
  • SXM [TBA]
       – Microsoft Research, C# library
25-Nov-11               PLDI 2005               26
            Related Work: Hardware

  • First wave
       – Herlihy&Moss 93, Stone et al. 93
  • Second wave
       – Rajwar&Goodman 02, Martinez&Torellas
         02, Oplinger&Lam 02, Hammond et al.
         04, Rajwar et al. 05



25-Nov-11              PLDI 2005            27
      Sadistic Homework Revisited
    Public void LeftEnq(item x) {
      Qnode q = new Qnode(x);
      q.left = this.left;
      this.left.right = q;
      this.left = q;
    }




                  Write sequential Code

25-Nov-11   (1)            PLDI 2005      28
            Transactions in SXM
    myDelegate
        = new XAction.Delegate(LeftEnq);
    XAction.Run(myDelegate, item);




    Create a delegate (function ptr) to
               your method


25-Nov-11            PLDI 2005             29
               Transactions
    myDelegate
        = new XAction.Delegate(LeftEnq);
    XAction.Run(myDelegate, item);




            Run it as a transaction



25-Nov-11            PLDI 2005             30
             Transactions in SXM
    myDelegate
        = new XAction.Delegate(LeftEnq);
    XAction.Run(myDelegate, item);




                No need to figure out:
            which locks protect which objects
            order of lock acquisition & release

25-Nov-11                PLDI 2005                31
                   Composition
    Public void Transfer(Queue q1, q2)
    {
      Item x = q1.deq();
      q2.enq(x);
    }




                  Trivial or what?

25-Nov-11   (1)         PLDI 2005        32
       Wake-ups: lost and found
    Public item LeftDeq() {
      if (this.left == null)
        XAction.Retry();
      …
    }



     Roll back transaction and restart
          when something changes
       (See PPoPP paper for details)
25-Nov-11   (1)      PLDI 2005           33
               OrElse Composition
    myDelegate1
        = new XAction.Delegate(q1.Deq);
    myDelegate2
        = new XAction.Delegate(q2.Deq)
    XAction.OrElse(myDelegate1,
                   myDelegate2);


            Run 1st method. If it retries …
            Run 2nd method. If it retries …
                Entire statement retries
                       See PPoPP paper
25-Nov-11                  PLDI 2005          34
     Optimistic Synchronization
  • “Easier to apologize than to ask
    permission”
  • Detects conflicts dynamically
       – If a conflict occurs
            • One transaction may abort another
       – If no conflict occurs
            • They run in parallel
  • Deadlock (practically) impossible

25-Nov-11                     PLDI 2005           35
       Old Wine in New Bottles?
  • Just another failed Utopian 20th
    Century ideology?
       – Effective when conflicts are rare
            • Low overhead, no waiting
       – Ineffective otherwise
            • Roll back, wasted work




25-Nov-11                   PLDI 2005        36
      Solution: Division of Labor
  • System
       – Detects conflicts
       – Rolls back & retries failed transactions
  • Contention Manager (user-provided)
       – Mediates conflict
       – Toolkit: backoff, queuing, aging, etc.
       – Performance issue, not correctness!

25-Nov-11                PLDI 2005                  37
       Ease of Use: Bottom Line
  • Used summer interns at Sun to design
    and implement complex, fine-grained
    concurrent data structures
       – Red-black trees, skew heaps, etc….
  • None were harmed
  • We defy you to try this with locks


25-Nov-11               PLDI 2005             38
       Open Research Questions
  • Some are subject of “serious dispute
    in high style”
  • Some are mysterious
  • All are fair game for PLDI community
       – Language Design
       – Implementation


25-Nov-11              PLDI 2005       39
            What is a Transaction?
  •   Replacement for critical section?
  •   Are transactions 1st-class objects?
  •   Is everything a transaction?
  •   Can transactions
       – Be long-lived?
       – Do remote method invocation?
       – Et cetera …

25-Nov-11              PLDI 2005            40
            Nested Transactions?
  • Some form of nesting is essential
       – Because method calls are nested
  • “Flat” nesting
       – Outermost only matters
       – Easy to implement
  • First-Class nesting
       – Needed for OrElse composition

25-Nov-11              PLDI 2005           41
              Types & Classes
  • Can any object be transactional?
       – Probably not
  • Is it an attribute of the class?
       – DSTM: no, use “wrapper” object
       – SXM: yes, & must follow conventions
       – STM Haskell: hell, yes.


25-Nov-11               PLDI 2005              42
            What about Libraries?
  • Do we need two copies of every
    library routine
       – One transaction-safe, one not
  • Is it like being thread-safe?
  • What about system calls?



25-Nov-11               PLDI 2005        43
             What about I/O?
  • Some I/O makes sense
       – Provide transaction-safe libraries
       – Undoable file system/DB calls
  • Some doesn’t
       – Opening cash drawer
       – Firing missile


25-Nov-11               PLDI 2005             44
            Interaction with non-
            transactional threads
  • Same questions raised by
       – Java memory group
       – Hans-J Boehm’s talk
  • Important
       – Transactional integrity preserved
       – Normal-case performance unaffected


25-Nov-11              PLDI 2005              45
            Wild & Crazy Models
  • Long-lived transactions
  • Distributed transactions
  • Compensating actions
       – Automatic apology after firing missile
  • Concurrency within transactions,
  • Integration with old-school
    (persistent) transactional systems
25-Nov-11               PLDI 2005                 46
             Contention Managers
  • What works and why?
  • Scherer and Scott [CSJP 04] tested
       – Backoff, randomized, various priority, …
       – None dominates on all benchmarks
  • Guerraoui, Herlihy, and Pochon        [PODC 05]
       – CMs that guarantee a competitive ratio against
         optimal off-line scheduler
  • Ideal combination of theory & practice

25-Nov-11                  PLDI 2005                  47
                 Consistency
  • Do transactions always see a
    consistent state?
       – Sometimes cheaper if “doomed”
         transactions don’t
       – OK if you can squash side-effects
       – Dubious otherwise



25-Nov-11               PLDI 2005            48
            Implementation Issues
  • Granularity of synchronization
       – Word or object?
  • Conflict detection
       – At run-time or commit-time?
  • Commit/Abort
       – Undo on abort?
       – Redo on commit?

25-Nov-11              PLDI 2005       49
                 Performance
  • Costs
       – CAS calls
       – Copying
  • Improvements possible
       – Compiler/postprocessor optimizations
       – Better data structures, algorithms, etc.


25-Nov-11               PLDI 2005               50
            Hardware Support
  • Will software TMs be fast enough?
       – We don’t know yet
  • Will we need hardware support?
       – Number of proposals exist
       – HW/SW division of responsibilities?




25-Nov-11              PLDI 2005               51
      Automatic Parallelization?
  • Effective parallelization must be
    aggressive, not afraid to make
    mistakes
  • But that requires synchronization
       – Locks can’t cut it
       – Maybe optimistic, non-blocking
         transactions can …

25-Nov-11               PLDI 2005         52
            My Penultimate Slide
  • A workshop on transactional issues in
    programming languages (broadly
    defined) is being planned to precede
    the next PLDI. Stay tuned …
  • Oh, and did I mention there is a
    PPoPP paper tomorrow on STM
    Haskell?

25-Nov-11           PLDI 2005           53
       I, for one, Welcome our new
           Multicore Overlords …
  • Multicore architectures force us to
    rethink how we do synchronization
  • Standard locking model won’t work
  • Transactional model might
       – Software
       – Hardware
  • A PLDI full-employment act!
25-Nov-11           PLDI 2005             54