Software Transactional Memory Should Not be Obstruction-Free CS510 Concurrent Systems Software Transactional Memory Should Not be Obstruction-Free

What is Obstruction Freedom? Weakest of the series of properties wait-free – every process must complete an operation after a finite number of steps (i.e. no starvation) lock-free – some process must complete an operation after a finite number of steps (i.e. no system-wide blocking) obstruction-free - a process is guaranteed to make progress when all other processes are stopped (i.e. no blocking by inactive processes) CS510 - Concurrent Systems

Why is Obstruction Freedom Useful? Distributed systems have independent failure domains obstruction freedom stops failed CPUs from preventing progress on healthy CPUs But is it useful in shared memory multi-core systems with a single failure domain? existing multi-core applications do not have this property do they need it? is STM interesting because of its obstruction freedom property, or for some other reason? CS510 - Concurrent Systems

CS510 - Concurrent Systems Causes of Obstruction? Threads become inactive for long periods due to: Failures Scheduling policies Blocking operations Priority inversions How are each of these situations handled in non-STM systems? CS510 - Concurrent Systems

Why is Obstruction Freedom Expensive? Because it precludes accessing object data in-place! Requires extra memory accesses for a level of indirection must go via an object descriptor to get to the object data Results in poor use of cache and TLB What if one process wants to access an object owned (being written to) by a swapped-out process? Wait? but that’s not obstruction-free! Go ahead? but that’s not safe Abort the blocked process and wait for acknowledgement? but that’s not obstruction-free either (may live-lock) CS510 - Concurrent Systems

Indirection in Obstruction-Free STM CS510 - Concurrent Systems

Why is Obstruction Freedom Expensive? Because it results in an excessive number of active transactions this increases memory contention If there are N transactions on N processors, what happens if we want to start another transaction Obstruction-free implementations can’t wait for other transactions to complete, so memory contention must increase CS510 - Concurrent Systems

Converting Existing Code to STM Threading for convenience convert lock-protected critical sections to transactions Threading for performance match number of active threads to number of CPUs poor mapping of threads to CPUs not solved by STM! CS510 - Concurrent Systems

STM Without Obstruction Freedom Revocable Two Phase Locking for Writes A transaction locks all objects it intends to write Locks are released when transaction completes 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 if no match, retry like sequence locks in Linux CS510 - Concurrent Systems

CS510 - Concurrent Systems Memory Layout CS510 - Concurrent Systems

CS510 - Concurrent Systems Writing If the object’s handle is a version number CAS handle to point to new write descriptor object is now locked Make private working copy of data why? Aborts, concurrent reads, … If the object’s handle is a write descriptor, wait Until it is a version number (ie until its unlocked) Or a timeout has been reached, then request other process to abort (if its lower priority than you) On deadlock, system aborts one transaction CS510 - Concurrent Systems

CS510 - Concurrent Systems Reading To read from an object Wait for handle to become a version wait until its unlocked once it is, proceed optimistically (i.e. without read locking it!) Log the version number so you can tell if you need to retry CS510 - Concurrent Systems

CS510 - Concurrent Systems Committing Make sure all read objects still have same version (check) Write working copy to original object (update) Set object’s descriptor to a new version (unlock) CS510 - Concurrent Systems

CS510 - Concurrent Systems Performance (1) CS510 - Concurrent Systems

CS510 - Concurrent Systems Performance (2) CS510 - Concurrent Systems

CS510 - Concurrent Systems Performance (3) CS510 - Concurrent Systems

Why the Poor Performance? Obstruction-Freedom effect on cache and TLB inability to co-locate data and meta-data in memory such that they map to the same cache line impacts performance in the uncontended case Helping occurs in the contended case contending transactions help others to finish transactions slow each other down more and more as the number of transactions involved in helping increases CS510 - Concurrent Systems

CS510 - Concurrent Systems Conclusion Obstruction freedom is not important to software transactional memory systems Obstruction freedom makes implementations: Inefficient Complicated Remove it from the requirements list! CS510 - Concurrent Systems