CS510 Concurrent Systems

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

2. 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

3. 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

4. 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

5. 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

6. Indirection in Obstruction-Free STM CS510 - Concurrent Systems

7. 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

8. 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 • convert lock-protected critical sections to transactions • poor mapping of threads to CPUs not solved by STM! CS510 - Concurrent Systems

9. 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

10. Memory Layout CS510 - Concurrent Systems

11. 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

12. 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

13. 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

14. Performance (1) CS510 - Concurrent Systems

15. Performance (2) CS510 - Concurrent Systems

16. Performance (3) CS510 - Concurrent Systems

17. 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

18. 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