1 / 16

Maintaining Multiple Versions in Software Transactional Memory

Maintaining Multiple Versions in Software Transactional Memory. Idit Keidar Dmitri Perelman Rui Fan. Aborts in STM. Forceful aborts – an algorithm suspects correctness violation Aborting transactions is bad work is lost resources are wasted overall throughput decreases

fadhila
Download Presentation

Maintaining Multiple Versions in Software Transactional Memory

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. Maintaining Multiple Versions in Software Transactional Memory IditKeidar Dmitri Perelman Rui Fan EuroTM 2011

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

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

  4. GC challenge • 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 T1 T2 o1 TM keeps the last 5 versions o2 A The needed version has been removed The sixth version is removed Past versions are kept though they will never be read EuroTM 2011

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

  6. Permissiveness in multi-versioned STM • 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) EuroTM 2011

  7. Space optimality for MV-permissiveness • 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 EuroTM 2011

  8. MV permissiveness vs DAP • 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 EuroTM 2011

  9. SMV: Selective Multi-Versioning STM • 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 EuroTM 2011

  10. GC challenge • 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 T1 T2 T2 o1 o1 Indistinguishable o2 o2 C C Kept Removed EuroTM 2011

  11. Automated GC in SMV • 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 EuroTM 2011

  12. SMV overview T1 T2 ver ≤ start time? o1 o2 o1 o2 ver = 10 ver = 5 ver = 10 ver = 5 C weak references to prev versions data5 data10 data10 data5 curPoint The value to be read time point 9 time point 10 T1 EuroTM 2011

  13. SMV GC Unneeded versiones are GCed automatically o1 o2 T1 T2 o1 ver = 10 ver = 10 o2 C C data10 data5 data5 data10 curPoint time point 9 time point 10 time point 11 T1 EuroTM 2011

  14. SMV performance • 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-dominated Vacation EuroTM 2011

  15. Conclusions • 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 EuroTM 2011

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

More Related