CS510 Concurrent Systems Class 13.ppt

CS510 - Concurrent Systems CS510 Concurrent Systems Class 13 Software Transactional Memory Should Not be Obstruction-Free What is Obstruction Freedom? CS510 - Concurrent Systems * Why is Obstruction Freedom Useful? 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 * Why is Obstruction Freedom Expensive? CS510 - Concurrent Systems * Indirection in Obstruction-Free STM CS510 - Concurrent Systems * 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 * 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 * 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 * Memory Layout CS510 - Concurrent Systems * Writing If the object’s handle is a version number CAS handle to po