cs510 concurrent systems class 13

18
CS510 Concurrent Systems Class 13 Software Transactional Memory Should Not be Obstruction-Free

Upload: don

Post on 25-Feb-2016

98 views

Category:

Documents


2 download

DESCRIPTION

CS510 Concurrent Systems Class 13. 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) - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: CS510 Concurrent Systems  Class 13

CS510 Concurrent Systems Class 13

Software Transactional Memory Should Not be

Obstruction-Free

Page 2: CS510 Concurrent Systems  Class 13

What is Obstruction Freedom?

CS510 - Concurrent Systems 2

Page 3: CS510 Concurrent Systems  Class 13

Why is Obstruction Freedom Useful?

CS510 - Concurrent Systems 3

Page 4: CS510 Concurrent Systems  Class 13

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

Page 5: CS510 Concurrent Systems  Class 13

Why is Obstruction Freedom Expensive?

CS510 - Concurrent Systems 5

Page 6: CS510 Concurrent Systems  Class 13

Indirection in Obstruction-Free STM

CS510 - Concurrent Systems 6

Page 7: CS510 Concurrent Systems  Class 13

Why is Obstruction Freedom Expensive? Because it results in an excessive number of

active transactionso 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

Page 8: CS510 Concurrent Systems  Class 13

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

Page 9: CS510 Concurrent Systems  Class 13

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 Reads

o 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

Page 10: CS510 Concurrent Systems  Class 13

Memory Layout

CS510 - Concurrent Systems 10

Page 11: CS510 Concurrent Systems  Class 13

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

Page 12: CS510 Concurrent Systems  Class 13

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

Page 13: CS510 Concurrent Systems  Class 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

Page 14: CS510 Concurrent Systems  Class 13

Performance (1)

CS510 - Concurrent Systems 14

Page 15: CS510 Concurrent Systems  Class 13

Performance (2)

CS510 - Concurrent Systems 15

Page 16: CS510 Concurrent Systems  Class 13

Performance (3)

CS510 - Concurrent Systems 16

Page 17: CS510 Concurrent Systems  Class 13

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

Page 18: CS510 Concurrent Systems  Class 13

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