Docstoc

Hazard Pointers Safe Memory Recl

Document Sample
Hazard Pointers Safe Memory Recl Powered By Docstoc
					Software Transactional Memory Should
Not Be Obstruction-Free

             Robert Ennals

              Presented by
               Abdulai Sei
Obstruction-Free

   Concept seen in previous paper by Maurice Herlihy
        “A Methodology for Implementing Highly concurrent Data Objects”
   Weakest of the series of properties
        wait-free - each process must complete an operation after taking a
         finite number of steps
        lock-free - a thread cannot lock up and every step it takes brings
         progress to the system
        obstruction-free - a thread is guaranteed to make progress when
         all other threads are suspended
   Essential in distributed systems (which is the background of
    most Software Transactional Memory researches)
Software Transactional Memory (STM) and
Obstruction-Freedom

   Obstruction-freedom is not a necessary property for STM in a
    non-distributed systems because
       use of STM is to improve performance of programs that would
        otherwise execute sequentially but with obstruction-freedom, this is
        a problem
       it is sometimes allowable for one transaction to block another
        transaction of the same or lower priority
       easy to adaptively vary the # of task to match available cores
            unlikely that a transaction will be blocked by a transaction that has
             been switched out
Threads and Tasks

   Thread and Tasks
       thread – a programmable level construct use to specify that several
        block of codes can be executed in parallel
       tasks (kernel thread)– OS level construct that runs on a core and
        execute code from threads
   Use of threads
       threading for convenience – can be ported to STM by converting all
        locks-protected blocks into transaction
       threading for performance – large program that previously uses
        small # of threads can now be broken down into small programs
        running on more threads
Application Parallelism

      critical to map application parallelism to underlining
       hardware parallelism and must be done carefully
           i.e. mapping kernel threads onto actual CPU
      building STM that tries to be immune to poor mapping does
       not solve the core problem
Motivation behind Obstruction-Freedom

   Prevent a long running transaction from blocking others
    transaction
        e.g – a transaction computes for a year then write to the same
         thread. Need to block other threads for this to happen
        obstruction-freedom guarantee progress if there are no other
         conflicting transactions
        lock-freedom only guarantee that the system as a whole make
         progress
   Prevent system locking
        occurs when a thread switch part-way through a transaction
        but guarantee the thread will be switch back – not a problem
   Prevent the system locking up if a thread fails
Why Obstruction-Freedom makes efficient
implementation difficult

   Obstruction–Freedom makes efficient implementation difficult
       Cache-Locality
            Object metadata must be adjacent to object data for unlikely cache
             misses
       Excessive Active Transaction
            Active transaction should not exceed number of cores causing new
             transactions to wait for free core
Implementation

   Based on concept in previous slides
   Idea
        revocable two phase locking for writes
            transaction locks all objects that it writes until it terminates

            what about dead lock?

        optimistic concurrency control for reads
            logs versions that transaction reads from

            verifies that versions are the same as the ones read when it

             commits
   Memory layout
        public memory – can be accessed by any transaction
        private memory – accessed by only transaction owner
Memory Layout
Implementation – (o=object, t=transaction)

   Writing an objects
       t must obtain an exclusive lock on o
           If o’s handle is a v

                  t uses atomic CAS to replace v with a pointer to a new write
                   descriptor
                  last-version field of write descriptor field set to v
                  working copy initialized to the current version of o data
            If o’s handle is a pointer to a write descriptor w
                  t waits until the owning transaction, s, sets the handle to be a
                   version number – indication it is finished
                  if t, timeout after some # of cycle, and s is of lower priority, t
                   request s aborts itself
                  t can find descriptor for s by zeroing the lower-order bits of w
                  What if deadlock is detected?
Implementation- continue

   Reading an object
        to read, t waits for o handler to be a version then logs the version number
         in the read descriptor
   Committing an object
        transaction checks that it is valid
            when is a transaction considered valid?

        then makes it write visible to other transactions
Performance
Performance Evaluation
Reasons for poor performance
   Obstruction-Freedom effect on cache and TLB
       due to the inability to colocate data and meta-data in memory such
        that they map to the same cache line
       affect performance in the uncontended case
   Helping
       applies to the contended case
       contending transaction help others to finish
       each transaction slows each other down as the number of
        transaction involve in helping increases
Conclusion

   Obstruction-freedom is not an important property for STMs
   Non-obstruction-freedom can achieve significantly better
    performance than an obstruction-free one
   Future designs should not attempt to be obstruction-free

				
DOCUMENT INFO