On Maintaining Multiple Versions in STM

1. On Maintaining Multiple Versions in STM IDIT KEIDAR AND DMITRI PERELMAN TECHNION

2. Why multiple versions • The use of multiple versions in TM is aimed to reduce the number of aborts • some aborts are unavoidable without maintaining multiple versions • The problem of maintaining multiple versions is highly correlated with the problem of avoiding unnecessary aborts T1 T2 o1 o2 C C keep the previous version of o2 cannot read the latest version – read the previous one

3. Abort policies • Conflict-based approach (abort upon a conflict) • conflict – two live transactions access the same object and at least one access is a write • single version per object • low computational complexity • some of the aborts are not essential for the correctness of the run – implementation reasons only (spurious aborts) • Precedence graph approach • aborts only upon cycle detection in the precedence graph • must keep multiple versions

4. Evaluating unnecessary aborts • Criterion for measuring unnecessary aborts – online opacity-permissiveness • do not abort if there is a way to return a value without violating correctness (opacity)

5. Garbage collection • Need to define the conditions for clearing the past versions of the objects • If TM wants to avoid unnecessary aborts: • may remove object version only if no txn will ever need to read it in future • The object version may be cleared at time t0: • only if the writer of the next version will have no live preceding txns from t0 onward T1 T2 o1 o2 C C

6. GC Woes • If a TM satisfies • online opacity-permissiveness • no real-time order requirements (e.g., serializability) then the GC condition is never satisfied • for any given Ti we may continue the run s.t. there will be a live txn preceding Ti • It follows that there exist runs with arbitrarily high number of object versions to keep • not GC friendly  • Informally, the problem is in allowing “installing the new versions before the last one”

7. Light opacity-permissiveness • Weakens online opacity-permissiveness to allow better GC • Informally, allows aborts when the only possible way to avoid the abort is to install the new version before the last one • if the only possible serialization order of txns writing to the same object contradicts with their commit order • no problem of “inserting the new version before the last one”

8. Light opacity-permissiveness – GC rules • Once the finished txn has no live preceding txns, it will have no live preceding txns in future • Once the writer of the version has committed and it has no live preceding txns, all the previous versions may be cleared T1 T2 o1 o2 C C Once T1 commits, T2 has no live preceding txns, previous version may be removed T2 has live preceding transaction, previous version must be kept

9. Multi-versioning – how to keep the versions? • Many TMs keep a list of n past versions • some kept versions are useless (no one will ever need to read them) • some versions are cleared in spite of the fact that they could be needed in future • a read operation has to traverse the versions till finding the appropriate one T1 T2 o1 TM keeps the list of 5 past object versions o2 A The needed version has been removed No txn will ever need to read these versions The sixth version has to be cleared

10. Smart Multi-Versioning STM • Satisfies light opacity-permissiveness • allows spare aborts but still has less aborts than any other TM existing today • In the runs without conflicts as light as other conflict-based TMs • only single version per object is kept • no precedence graphs calculations • Each past version is kept if and only if it has a potential reader in future • referenced by the potential readers only • garbage collection can be automatic

11. SMV TM Overview • Object handler keeps only the last version of the object • The overridden versions are referenced by the overriding transaction • if they have no potential readers they are thrown away • Transactions’ descriptors form a subgraph of the precedence graph • in the runs without conflicts no need for that • Object handler keeps the live txns that precede the writer of the last object version • in this way the information about live preceding txns passes to the new txns

12. SMV TM Overview – cont. Conflict is detected T1 T2 read list: T1 prec list: o1 read list: prec list: o2 v1 v2 T1 C C Previous version is kept No need to keep these versions T2 descriptor T1 descriptor conflict = prev. versions: true false conflict = true prev. versions: precedes o2.v1 Garbage Collected Garbage Collected Garbage Collected

13. Summary • TM avoiding unnecessary aborts must keep too many past versions • our new measure light opacity-permissiveness allows more liberal GC rules • GC is an important consideration for making TMs work in the “real world” • Introduced smart multi-versioning STM • light opacity-permissiveness (less spare aborts than existing TMs) • in runs without conflicts - as light as conflict-based counterparts • keeps object versions iff they have potential readers • no need to worry about garbage collection!

14. Thank you!