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