MULTIVIE W Slide 1 (of 21) Software Transactional Memory Should Not Be Obstruction Free Paper: Robert Ennals Presenter: Emerson Murphy-Hill

MULTIVIE W Slide 2 (of 21) What We’ve Seen Thus Far… Hardware and software transactions No performance data STM striving to be obstruction-free: –A process will make progress in a finite number of steps in the absence of contention –The weakest progress guarantee –Introduces the possibility of livelock, which can be addressed through contention management (helping / stealing) The message: the weaker the progress guarantee, the simpler the implementation…

MULTIVIE W Slide 3 (of 21) The Gist of this Paper: Obstruction-freedom is an unnecessary guarantee for transactional memory Obstruction-freedom makes implementation difficult Without obstruction-freedom, performance is fine

MULTIVIE W Slide 4 (of 21) Threads In real programs, concurrency is implemented with threads Threads are used for convenience: –No performance advantage for single-core machines –Convenience allows one thread to proceed while another blocks –For instance, GUI and compute threads –Only locks needed; that’s fine for single-core –Different priority locks may be needed to ensure low priority threads don’t block high priority threads

MULTIVIE W Slide 5 (of 21) Threads (continued) Threading for performance: –In the presence of multi-cores, multi-threads are good! We expect locks in threaded code converted to transactions automatically The key: since the original, locked code could block a process, it’s acceptable for the new STM code to block as well

MULTIVIE W Slide 6 (of 21) Obstruction Freedom is Unnecessary

MULTIVIE W Slide 7 (of 21) Long Running Transactions Block Others Straw-man or Herlihy: long-running/non- terminating transactions can cause other transactions to block without obstruction- freedom Wrong! This happens anyway: –Suppose we have a read to an object, a year- long compute, then a write to the same object –All STM implementations can only block other transactions

MULTIVIE W Slide 8 (of 21) Context Switching Straw-man or Herlihy: the system grinds to a halt when the OS switches tasks Wrong! Here’s why: –The task will be switched back in again –In a good implementation, this will be rare, because the number of tasks should equal the number of processors –There should be no blocking in transactions anyway: It wasn’t allowed in the original locked implementation Transaction-aware operating systems can prevent it

MULTIVIE W Slide 9 (of 21) Independent Failure Straw-man or Herlihy: On software or hardware failure, system grinds to halt Wrong! –Software or hardware failure broke the lock- based implementation, so it’s fine –Hardware failure is rare in multi-cores anyway

MULTIVIE W Slide 10 (of 21) Obstruction Freedom makes Implementation Difficult

MULTIVIE W Slide 11 (of 21) Cache-locality STM usually requires several memory accesses before an object can be accessed What if one process wants to access an object owned by swapped- out process? –Wait, but that’s not obstruction-free –Go ahead, but that’s not safe –Could abort the blocked process and wait for acknowledgement, but that’s not obstruction-free either (also, might live-lock) So: STM cannot store object data in-place

MULTIVIE W Slide 12 (of 21) Excessive Active Transactions If there are N transactions on N processors, what happens if we want to add another transaction? Obstruction-free implementations can’t wait for other transactions to complete, so memory contention must increase

MULTIVIE W Slide 13 (of 21) Life without Obstruction- Freedom…

MULTIVIE W Slide 14 (of 21) The Basic Idea Revocable Two Phase Locking for Writes –A transaction locks all objects it intends to write –Locks are released when transaction is complete –On deadlock, one transaction aborts and rolls back it’s writes Optimistic Concurrency Control for Reads –Objects log the version number they read –Version numbers must match end-of-transaction version numbers on commit

MULTIVIE W Slide 15 (of 21) Memory Layout

MULTIVIE W Slide 16 (of 21) Reading and Writing To write to an object: –If the object’s handle is a version number CAS handle to point to new write descriptor Make private working copy –If the object’s handle is a write descriptor, wait Until it is a version number Or a timeout has been reached, then request other process to abort –On deadlock, system aborts one transaction To read from an object –Wait for handle to become a version –Log the version

MULTIVIE W Slide 17 (of 21) Committing Make sure all read objects still have same version Write working copy to original object Set object’s descriptor to a new version The runtime must periodically check for invalid transactions (transactions that are in infinite loops because they’ve seen inconsistent data)

MULTIVIE W Slide 18 (of 21) Performance

MULTIVIE W Slide 19 (of 21) Performance (continued)

MULTIVIE W Slide 20 (of 21) Performance (continued)

MULTIVIE W Slide 21 (of 21) Conclusion Obstruction freedom is not important to software transactional memory systems Obstruction freedom makes implementations: –Inefficient –Complicated So do away with it!