Presentation is loading. Please wait.

Presentation is loading. Please wait.

IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1.

Similar presentations


Presentation on theme: "IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1."— Presentation transcript:

1 IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1

2 Aborts in STM EuroTM 2011 Forceful aborts – an algorithm suspects correctness violation Aborting transactions is bad  work is lost  resources are wasted  overall throughput decreases  danger of livelock 2

3 Multi-versioning in STM EuroTM 2011 Keeping multiple versions can prevent aborts 3 o1 o2 CC cannot read the latest version – read the previous one o1 o2 C cannot read the latest version – abort A T1T2T1T2 Single-versioned STMMulti-versioned STM

4 GC challenge EuroTM Must clean up the old versions Some existing TMs keep a list of n past versions  some kept versions are useless  some potentially useful versions are removed o1 o2 The sixth version is removed The needed version has been removed A TM keeps the last 5 versions Past versions are kept though they will never be read T1T2

5 Memory growth EuroTM k versions => k times more memory?  No! It can be much worse…  Consider pointer-based data structures replace 30 with 40 replace 20 with 25 replace 40 with 50 replace 50 with 60 Complete binary tree for a linked list

6 Permissiveness in multi-versioned STM EuroTM 2011 Multi-Versioned (MV)-Permissiveness  each read-only transaction commits  an update transaction aborts only if it conflicts with another update transaction Practical – satisfied by Vboxes, SMV  would have been achieved by most multi-versioned algorithms  if they had kept all the needed object versions Responsive STM  a txn operation does not wait for other transactions to invoke new txn operations  to avoid trivial “global lock” solutions (no aborts and no concurrency) 6

7 Space optimality for MV-permissiveness EuroTM Space optimality  An MV-permissive STM1 is space optimal if for any MV- permissive STM2 at any point of time:  #versions in STM1 ≤ #versions in STM2 No responsive MV-permissive STM can be space optimal Sometimes, it’s impossible to know whether to remove an old version  could save the need to keep other versions in future

8 MV permissiveness vs DAP EuroTM 2011 Disjoint Access Parallelism (DAP) property: txns with disjoint data sets do not contend (no “common bottleneck”) A responsive MV-permissive STM cannot be DAP Intuitively, contention point is “responsible” for real- time order guarantee  can forfeit RTO and satisfy DAP 8

9 SMV: Selective Multi-Versioning STM EuroTM Responsive and MV-Permissive  each read-only transaction commits  cannot be space-optimal  cannot be DAP Versions are kept as long as they might be needed Read-only transactions are invisible to other transactions  do not change data that can be read by others  avoids cache thrashing

10 GC challenge EuroTM No transaction can know whether a given version can be removed  explicit GC is not possible A version is removed when it has no potential readers Readers are invisible o1 o2 C T1T2 o1 o2 C T2 Kept Removed Indistinguishable

11 Automated GC in SMV EuroTM Solution: use auxiliary GC threads provided by managed memory systems  remove unreachable object versions Read-only transactions are invisible to other transactions, but visible to the “see-all” GC threads  theoretically visible  practically invisible  GC threads run infrequently  does not add cache-coherency overhead

12 SMV overview EuroTM curPoint time point 9 T1 ver = 5 o1o1 data 5 o1 o2 ver = 5 o2o2 data 5 C time point 10 ver = 10 data 10 T1T2 weak references to prev versions ver ≤ start time? The value to be read

13 SMV GC EuroTM curPoint time point 9 o1o1 data 5 o1 o2 o2o2 data 5 C time point 10 ver = 10 data 10 C time point 11 T1T2 T1 Unneeded versiones are GCed automatically

14 SMV performance EuroTM Great for read-dominated workloads  especially with long read operations (snapshot, aggregation, etc.) Low overhead if there are no read-only transactions at all STMBench7 read-dominatedVacation

15 Conclusions EuroTM Multi-versioning can improve STM performance  especially useful for long read-only transactions Keeping a constant number of versions is not efficient  not every needed version can be found  exponential memory growth MV-permissiveness imposes overheads of its own  cannot be space efficient  cannot be DAP SMV uses automatic GC capabilities for deleting old versions  the readers stay invisible

16 References EuroTM On Maintaining Multiple Versions in STM  Perelman, Keidar, Fan, PODC’10 SMV: Selective Multi-Versioning STM  Perelman, Byshevsky, Litmanovich, Keidar, submitted


Download ppt "IDIT KEIDAR DMITRI PERELMAN RUI FAN EuroTM 2011 Maintaining Multiple Versions in Software Transactional Memory 1."

Similar presentations


Ads by Google