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

What is Obstruction Freedom?  Weakest of the series of properties o wait-free – every process must complete an operation after a finite number of steps (i.e. no starvation) o lock-free – some process must complete an operation after a finite number of steps (i.e. no system-wide blocking) o 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 2

Why is Obstruction Freedom Useful?  Distributed systems have independent failure domains o 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? o existing multi-core applications do not have this property do they need it? o is STM interesting because of its obstruction freedom property, or for some other reason? CS510 - Concurrent Systems 3

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

Why is Obstruction Freedom Expensive?  Because it precludes accessing object data in-place! o Requires extra memory accesses for a level of indirection must go via an object descriptor to get to the object data o 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? o Wait? but that’s not obstruction-free! o Go ahead? but that’s not safe o Abort the blocked process and wait for acknowledgement? but that’s not obstruction-free either (may live-lock) CS510 - Concurrent Systems 5

Indirection in Obstruction-Free STM CS510 - Concurrent Systems 6

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

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

STM Without Obstruction Freedom  Revocable Two Phase Locking for Writes o A transaction locks all objects it intends to write o Locks are released when transaction completes o On deadlock, one transaction aborts and rolls back it’s writes  Optimistic Concurrency Control for Reads o Objects log the version number they read o Version numbers must match end-of-transaction version numbers on commit o if no match, retry o like sequence locks in Linux CS510 - Concurrent Systems 9

Memory Layout CS510 - Concurrent Systems 10

Writing  If the object’s handle is a version number o CAS handle to point to new write descriptor object is now locked o Make private working copy of data why? Aborts, concurrent reads, …  If the object’s handle is a write descriptor, wait o Until it is a version number (ie until its unlocked) o 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 11

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

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 13

Performance (1) CS510 - Concurrent Systems 14

Performance (2) CS510 - Concurrent Systems 15

Performance (3) CS510 - Concurrent Systems 16

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

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