1. Software Transactional Memory Should Not be Obstruction-Free
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. 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

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
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. CS510 - Concurrent Systems
Memory Layout
CS510 - Concurrent Systems

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

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

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

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

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

16. CS510 - Concurrent Systems
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. 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