Download presentation
Presentation is loading. Please wait.
1
CS510 Concurrent Systems Class 13 Software Transactional Memory Should Not be Obstruction-Free
2
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
3
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
4
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
5
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
6
Indirection in Obstruction-Free STM CS510 - Concurrent Systems 6
7
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
8
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
9
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
10
Memory Layout CS510 - Concurrent Systems 10
11
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
12
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
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 13
14
Performance (1) CS510 - Concurrent Systems 14
15
Performance (2) CS510 - Concurrent Systems 15
16
Performance (3) CS510 - Concurrent Systems 16
17
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
18
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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.