1 / 18

CS510 Concurrent Systems

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)

sgrundy
Télécharger la présentation

CS510 Concurrent Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related