CS510 Concurrent Systems Class 13

Software Transactional Memory Should Not be

Obstruction-Free

What is Obstruction Freedom?

CS510 - Concurrent Systems 2

Why is Obstruction Freedom Useful?

CS510 - Concurrent Systems 3

Causes of Obstruction?

Threads become inactive for long periods due to:o Failureso Scheduling policieso Blocking operationso Priority inversions

How are each of these situations handled in non-STM systems?

CS510 - Concurrent Systems 4

Why is Obstruction Freedom Expensive?

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 convenienceo convert lock-protected critical sections to transactions

Threading for performanceo match number of active threads to number of CPUso convert lock-protected critical sections to transactionso poor mapping of threads to CPUs not solved by STM!

CS510 - Concurrent Systems 8

STM Without Obstruction Freedom

Revocable Two Phase Locking for Writeso A transaction locks all objects it intends to writeo Locks are released when transaction completeso On deadlock, one transaction aborts and rolls back it’s

writes

Optimistic Concurrency Control for Readso Objects log the version number they reado Version numbers must match end-of-transaction

version numbers on commito if no match, retryo 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 lockedo Make private working copy of data

• why? Aborts, concurrent reads, …

If the object’s handle is a write descriptor, waito 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 objecto 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 TLBo inability to co-locate data and meta-data in memory

such that they map to the same cache lineo impacts performance in the uncontended case

Helpingo occurs in the contended caseo contending transactions help others to finisho 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 Inefficiento Complicated

Remove it from the requirements list!

CS510 - Concurrent Systems 18