An Efficient Approach to Achieve Compositionality using Optimized Multi-Version Object Based Transactional Systems

An Efficient Approach to Achieve Compositionality using Optimized Multi-Version Object Based Transactional

Systems

¹

Chirag Juyal¹, Sandeep Kulkarni², Sweta Kumari¹, Sathya Peri¹and Archit Somani¹²

Department of Computer Science & Engineering, IIT Hyderabad, India¹

(cs17mtech11014, cs15resch01004, sathya p, cs15resch01001)@iith.ac.in Department of Computer Science, Michigan State University, MI, USA²

sandeep@cse.msu.edu

Abstract

In the modern era of multi-core systems, the main aim is to utilize the cores properly.

This utilization can be done by concurrent programming. But developing a flawless and well-organized concurrent program is difficult. Software Transactional Memory Systems (STMs) are a convenient programming interface which assist the programmer to access the shared memory concurrently without worrying about consistency issues such as priority-inversion, deadlock, livelock, etc. Another important feature that STMs facilitate is compositionality of concurrent programs with great ease. It composes different concurrent operations in a single atomic unit by encapsulating them in a transaction.

Many STMs available in the literature execute read/write primitive operations on memory buffers. We represent them asRead-Write STMsorRWSTMs. Whereas, there exist some STMs (transactional boosting and its variants) which work on higher level operations such as insert, delete, lookup, etc. on a hash-table. We refer these STMs as Object Based STMs or OSTMs.

The literature of databases and RWSTMs say that maintaining multiple versions

1A preliminary version of this paper appeared in 20th International Symposium on Stabilization, Safety, and Security of Distributed Systems (SSS 2018) and awarded with theBest Student Paper Award. A poster version of this work receivedBest Poster Awardin NETYS 2018.

2Author sequence follows the lexical order of last names. All the authors can be contacted at the addresses given above. Archit Somani’s phone number: +91 - 7095044601.

arXiv:1905.01200v1 [cs.DC] 3 May 2019

ensures greater concurrency. This motivates us to maintain multiple version at higher level with object semantics and achieves greater concurrency. So, this paper pro- poses the notion ofOptimized Multi-version Object Based STMsorOPT-MVOSTMs which encapsulates the idea of multiple versions in OSTMs to harness the greater con- currency efficiently. For efficient memory utilization, we develop two variations of OPT-MVOSTMs. First,OPT-MVOSTMwith garbage collection (orOPT-MVOSTM-GC) which uses unbounded versions but performs garbage collection scheme to delete the unwanted versions. Second, finite versionOPT-MVOSTM(orOPT-KOSTM) which maintains at mostKversions by replacing the oldest version when(K+ 1)^thversion is created by the current transaction.

We propose theOPT-MVOSTMsfor hash-table and list objects asOPT-HT-MVOSTM andOPT-list-MVOSTMrespectively. For memory utilization, we propose two vari- ants of both the algorithms asOPT-HT-MVOSTM-GC,OPT-HT-KOSTMandOPT-list- MVOSTM-GC,OPT-list-KOSTMrespectively.OPT-HT-KOSTMperforms best among its variants and outperforms state-of-the-art hash-table based STMs (HT-OSTM, ESTM, RWSTM, HT-MVTO, HT-KSTM) by a factor of 3.62, 3.95, 3.44, 2.75, 1.85 for work- load W1 (90% lookup, 8% insert and 2% delete), 1.44, 2.36, 4.45, 9.84, 7.42 for workload W2 (50% lookup, 25% insert and 25% delete), and 2.11, 4.05, 7.84, 12.94, 10.70 for workload W3 (10% lookup, 45% insert and 45% delete) respectively. Similarly, OPT-list-KOSTMperforms best among its variants and outperforms state-of-the-art list based STMs (list-OSTM, Trans-list, Boosting-list, NOrec-list, list-MVTO, list-KSTM) by a factor of 2.56, 25.38, 23.57, 27.44, 13.34, 5.99 for W1, 1.51, 20.54, 24.27, 29.45, 24.89, 19.78 for W2, and 2.91, 32.88, 28.45, 40.89, 173.92, 124.89 for W3 respectively.

OPT-MVOSTMsare generic for other data structures as well. We rigorously proved that OPT-MVOSTMs satisfy opacity and ensure that transaction with lookup only methods will never return abort while maintaining unbounded versions.

Keywords: Software Transactional Memory Systems, Optimized, Lazyrb-list, Hash-Table, List, Object, Multi-version, Compositionality, Opacity, Keys

1. Introduction

Nowadays, multi-core systems are in trend which necessitated the need for concur- rent programming to exploit the cores appropriately. Howbeit, developing the correct and efficient concurrent programs is difficult. Software Transactional Memory Systems (STMs) are a convenient programming interface which assist the programmer to access the shared memory concurrently using multiple threads without worrying about con- sistency issues such as deadlock, livelock, priority-inversion, etc. STMs facilitate one more feature compositionality of concurrent programs with great ease which makes it more approachable. Different concurrent operations that need to be composed to form a single atomic unit is achieved by encapsulating them in a transaction. In this paper, we discuss various STMs such as read-write STMs (or RWSTMs), object based STMs (or OSTMs) available in the literature along with the benefits of OSTMs over RWSTMs.

After that, we motivated from multi-version RWSTMs and propose multi-version object based STMs (or MVOSTMs) [1] which maintain multiple versions and improves the concurrency further. Later, we made a couple of modifications (discussed in Section 4, Section 5, and Section 7) to optimize the MVOSTMs and propose optimized MVOSTMs (orOPT-MVOSTMs).

Read-Write STMs:There exists a lot of popular STMs in the literature such as ESTM [2], NOrec [3] which executes read/write operations ontransaction objectsort-objects.

We represent these STMs asRead-Write STMsorRWSTMs. RWSTMs typically export following methods: (1)t begin: which begins a transaction with a unique identity, (2) t read(orr): which reads the value of t-object from shared memory, (3)t write(orw):

which writes the new value to t-object in its local memory, (4)tryC: which validates the values written to t-objects by the transaction and tries to commit. If all the updates made by the transaction is consistent then updates reflect to the shared memory and transaction returns commit, and (5)tryA: which returns abort on any inconsistency.

Object based STMs:There are few STMs available in the literature which executes higher level operations such as insert, delete, lookup on hash-table. We represent these STMs asObject based STMsorOSTMs. The concept of Boosting by Herlihy et al. [4], the optimistic variant by Hassan et al. [5] and recentlyHT-OSTMsystem by Peri et al.

RWSTMs r−w

w−r (c) at Layer−0

(b) H1: Transactional tree history (a) Underlying hash−table

(d) at Layer−1 OSTMs

T2

T1

c2

r1(k3) r1(k3) r1(k8)

Layer-0: Reads & Writes T2

k8

T1

r2(k6)

Deletes k3

r2(k3)

lu1(k3) del2(k6) 2

1

3

B T1 T2

k6

Layer-1: Lookups &

lu1(k8)

w2(k6) w2(k3)

Figure 1: Advantages of OSTMs over RWSTMs

[6] are some examples that demonstrate the performance benefits achieved byOSTMs.

Peri et al. [6] showed thatOSTMs provide greater concurrency than RWSTMs while reducing the number of aborts.

Benefits ofOSTMs overRWSTMs: To show the benefits ofOSTMs, We consider a hash-table based STM system which invokes insert (orins), lookup (orlu) and delete (ordel) method. Each hash-table consists ofBbuckets with the elements in each bucket arranged in the form of a linked-list. Figure 1 (a) represents a hash-table with the first bucket containing keyshk3, k6, k8i. Figure 1 (b) shows the execution by two transactionT1andT2represented in the form of a tree.T1performs lookup operations on keysk3andk8whileT2performs a delete onk6. The delete on keyk6generates read on the keysk3, k6and writes the keysk6, k3assuming that delete is performed similar to delete operation in lazy-list [7]. The lookup onk3generates read onk3while the lookup onk₈generates read onk₃, k₈. Note that in this executionk₆has already been deleted by the time lookup onk₈is performed.

In this execution, we denote the read-write operations (leaves) as layer-0 andlu, del methods as layer-1. Consider the history (execution) at layer-0 (while ignoring higher- level operations), denoted asH0. It can be verified this history is not opaque [8]. This is because, between the two reads ofk3byT1,T2writes tok3. It can be seen that if historyH0is input to anRWSTMs one of the transactions betweenT1orT2would be aborted to ensure opacity [8]. Figure 1 (c) shows the presence of a cycle in the conflict graph ofH0.

Now, consider the historyH1 at layer-1 consists oflu, anddel methods, while

(c) SV−OSTMs

(d) OPT−MVOSTMs (a) Single−version OSTMs (SV−OSTMs) (b) Optimized Multi−version OSTMs

lu1(ht, k2, v0) T1 T2

del-lu lu-ins

C2

C1

ins2(ht, k3, v3) del2(ht, k2, v0) C2

A1

T1

T2

T1

T2

ins2(ht, k3, v3) del2(ht, k2, v0) lu1(ht, k3, null) lu1(ht, k2, Abort) lu1(ht, k3, null)

T1 T2

lu-ins

Figure 2: Advantages of optimized multi-version over single versionOSTM

ignoring the read/write operations since they do not overlap (referred to as pruning in [9, Chap 6]). These methods work on distinct keys (k₃,k₆, andk₈). They do not overlap and are not conflicting. So, they can be re-ordered in either way. Thus,H1is opaque [8] with equivalent serial historyT₁T₂(orT₂T₁) and the corresponding conflict graph shown in Figure 1 (d). Hence, a hash-table basedOSTMsystem does not abort any of T1orT2. This shows thatOSTMs can reduce the number of aborts and provide greater concurrency.

Multi-Version Object Based STMs:Some of theOSTMs such as [4], [5], [6] exploits the advantages of it. In this paper, we propose and analyzeOptimized Multi-version Object Based STMsorOPT-MVOSTMsalong with the rigorous correctness proof. This work is motivated by the observation that databases andRWSTMs achieves greater con- currency by storing multiple versions corresponding to each t-object [10]. Specifically, maintaining multiple versions can ensure that more read operations succeed because the reading operation will obtain an appropriate version to read. Our goal is to analyze the benefit ofOPT-MVOSTMsover both single versionOSTMs and multi-versionRWSTMs.

The potential benefit ofOPT-MVOSTMsoverOSTMs and multi-versionRWSTMs:

We now illustrate the advantage ofOPT-MVOSTMsas compared to single-version OSTMs (SV-OSTMs) using the hash-table object with B buckets having the same operations as discussed above: ins, lu, del. Figure 2 (a) represents a history H with two concurrent transactionsT1 andT2operating on a hash-tableht. T1first tries to perform aluon keyk3. But due to the absence of keyk3inht, it obtains a value of null. ThenT2invokesinsmethod on the same keyk3and inserts the valuev3inht.

ThenT₂deletes the keyk₂fromhtand returnsv₀implying that some other transaction had previously insertedv₀intok₂. The second method ofT₁isluon the keyk₂. With this execution, anySV-OSTMsystem has to return abort forT₁’sluoperation to ensure

correctness, i.e., opacity. Otherwise, ifT1would have obtained a return valuev0for k2, then the history would not be opaque anymore. This is reflected by a cycle in the corresponding conflict graph betweenT1andT2, as shown in Figure 2 (c). Thus to ensure opacity,SV-OSTMsystem has to return abort forT₁’s lookup onk₂.

In anOPT-MVOSTMsbased on hash-table, denoted asOPT-HT-MVOSTM, whenever a transaction inserts or deletes a keyk, a new version is created. Consider the above example with anOPT-HT-MVOSTM, as shown in Figure 2 (b). Even afterT₂deletesk₂, the previous value ofv0is still retained. Thus, whenT1invokesluonk2after the delete onk2byT2,OPT-HT-MVOSTMreturnv0(as previous value). With this, the resulting history is opaque with equivalent serial history beingT1T2. The corresponding conflict graph is shown in Figure 2 (d) does not have a cycle.

Thus,OPT-MVOSTMreduces the number of aborts and achieve greater concurrency thanSV-OSTMs while ensuring the compositionality. We believe that the benefit of OPT-MVOSTMover multi-versionRWSTMis similar toSV-OSTMover single-version RWSTMas explained above.OPT-MVOSTMis a generic concept which can be applied to any data structure. In this paper, we have considered the hash-table and list based OPT-MVOSTMsasOPT-HT-MVOSTM andOPT-list-MVOSTMrespectively. If the bucket sizeBof hash-table becomes 1 then hash-table basedOPT-MVOSTMsboils down to the list basedOPT-MVOSTMs.

OPT-HT-MVOSTMandOPT-list-MVOSTMuse an unbounded number of versions for each key. To address this issue, we develop two variants for both hash-table and list data structures (or DS): (1) A garbage collection method inOPT-MVOSTMsto delete the unwanted versions of a key, denoted asOPT-MVOSTM-GC. Garbage collection gave an average performance gain of 16% overOPT-MVOSTMwithout garbage collection in the best case. Thus, the overhead of garbage collection scheme is less than the performance improvement due to improved memory usage. (2) Placing a limit ofKon the number versions inOPT-MVOSTM, resulting inOPT-KOSTM. This gave an average performance gain of 24% overOPT-MVOSTMwithout garbage collection in the best case.

Experimental results show thatOPT-HT-KOSTMperforms best among its variants and outperforms state-of-the-art hash-table based STMs (HT-OSTM, ESTM, RWSTM,

HT-MVTO, HT-KSTM) by a factor of 3.62, 3.95, 3.44, 2.75, 1.85 for workload W1 (90% lookup, 8% insert and 2% delete), 1.44, 2.36, 4.45, 9.84, 7.42 for workload W2 (50% lookup, 25% insert and 25% delete), and 2.11, 4.05, 7.84, 12.94, 10.70 for workload W3 (10% lookup, 45% insert and 45% delete) respectively. Similarly, OPT-list-KOSTMperforms best among its variants and outperforms state-of-the-art list based STMs (list-OSTM, Trans-list, Boosting-list, NOrec-list, list-MVTO, list-KSTM) by a factor of 2.56, 25.38, 23.57, 27.44, 13.34, 5.99 for W1, 1.51, 20.54, 24.27, 29.45, 24.89, 19.78 for W2, and 2.91, 32.88, 28.45, 40.89, 173.92, 124.89 for W3 respectively.

To the best of our knowledge, this is the first work to explore the idea of using multiple versions inOSTMs to achieve greater concurrency.

Contributions of the paper:

• We propose a new notion of optimized multi-version objects based STM system asOPT-MVOSTM in Section 4. In this paper, we develop it for list and hash- table objects asOPT-list-MVOSTMandOPT-HT-MVOSTMrespectively.OPT- MVOSTMis generic for other data structures as well.

• For efficient space utilization inOPT-MVOSTMswith unbounded versions, we developGarbage CollectionforOPT-MVOSTM(i.e.OPT-MVOSTM-GC) and bounded versionOPT-MVOSTM(i.e.OPT-KOSTM).

• Section 6 shows thatOPT-list-MVOSTMandOPT-HT-MVOSTMsatisfy standard correctness-criterion of STMs,opacity[8].

• Experimental analysis of bothOPT-list-MVOSTMandOPT-HT-MVOSTMwith state-of-the-art STMs are present in Section 7. ProposedOPT-list-MVOSTM andOPT-HT-MVOSTMprovide greater concurrency and reduces the number of aborts as compared toMVOSTMs,SV-OSTMs, single-versionRWSTMs and, multi-versionRWSTMs while maintaining multiple versions corresponding to each key.

Roadmap:The paper is organized as follows. We describe our building system model in Section 2. In Section 3, we formally define the graph characterization of opacity.

Section 4 represents theOPT-MVOSTMsdesign and data structure. Section 5 shows the

working ofOPT-HT-MVOSTMsand its algorithms. We formally prove the correctness ofOPT-MVOSTMsin Section 6. In Section 7 we show the experimental evaluation of OPT-MVOSTMswith state-of-art-STMs. Finally, we conclude in Section 8.

2. Building System Model

Our assumption follows [11, 6] in which the system consists of a finite set of pprocesses, p1, . . . , pn, accessed by a finite number of nthreads in a completely asynchronous fashion and communicates each other using shared keys (or objects).

The threads invoke higher level methods on the shared objects and get corresponding responses. Consequently, we make no assumption about the relative speeds of the threads. We also assume that none of these processors and threads fail or crash abruptly.

Events and Methods:We assume that the threads execute atomiceventsand the events by different threads are (1) read/write on shared/local memory objects, (2) method invocations (orinv) event and responses (orrsp) event on higher level shared memory objects.

Within a transaction, a process can invoke layer-1 methods (or operations) on a hash-tablet-object. A hash-table(ht) consists of multiple key-value pairs of the form hk, vi. The keys and values are respectively from setsK andV. The methods that a thread can invoke are: (1)t begin_i(): begins a transaction and returns a unique id to the invoking thread. (2)t inserti(ht, k, v): transactionTiinserts a valuevonto key kinht. (3)t deletei(ht, k, v): transactionT_ideletes the key kfrom the hash-table htand returns the current valuevforT_i. If keykdoes not exist, it returnsnull. (4) t lookup_i(ht, k, v): returns the current valuevfor keykinhtforT_i. Similar tot delete, if the keykdoes not exist thent lookupreturnsnull. (5)tryC_i(): which tries to commit all the operations ofTiand (6)tryA_i(): abortsTi. We assume that each method consists of aninvandrspevent.

We denotet insertandt deleteasupdatemethods (orupd methodorup) since both of these change the underlying data structure. We denotet deleteandt lookupas return-value methods (orrv methodorrvm)as these operations return values fromht.

A method may returnokif successful orA(abort) if it sees an inconsistent state ofht.

Formally, we denote a methodmby the tuplehevts(m), <mi. Here,evts(m)are all the events invoked bymand the<ma total order among these events.

Transactions:Following the notations used in database multi-level transactions[9], we model a transaction as a two-level tree. Thelayer-0consist of read/write events and layer-1of the tree consists of methods invoked by a transaction.

Having informally explained a transaction, we formally define a transactionT as the tuplehevts(T), <_Ti. Hereevts(T)are all the read/write events atlayer-0of the transaction.<_T is a total order among all the events of the transaction.

We denote the first and last events of a transactionT_iasT_i.f irstEvtandT_i.lastEvt.

Given any other read/write eventrwinTi, we assume thatTi.f irstEvt <T_irw <T_i

Ti.lastEvt. All the methods ofTiare denoted asmethods(Ti). We assume that for any methodminmethods(Ti),evts(m)is a subset ofevts(Ti)and<mis a subset of

<T_i. We assume that if a transaction has invoked a method, then it does not invoke a new method until it gets the response of the previous one. Thus all the methods of a transaction can be ordered by<T_i. Formally,(∀mp, mq ∈methods(Ti) : (mp <T_i

mq)∨(mq<Ti mp))i, herempandmq arepthandqthmethods ofTirespectively.

Histories:Ahistoryis a sequence of events belonging to different transactions. The collection of events is denoted asevts(H). Similar to a transaction, we denote a history Has tuplehevts(H), <_Hiwhere all the events are totally ordered by<_H. The set of methods that are inHis denoted bymethods(H). A methodmisincompleteif inv(m) is inevts(H)but not its corresponding response event. Otherwise,miscompleteinH.

Coming to transactions inH, the set of transactions inHare denoted astxns(H).

The set of committed (resp., aborted) transactions inH is denoted bycommitted(H) (resp., aborted(H)). The set oflivetransactions in H are those which are neither committed nor aborted and denoted as live(H) = txns(H)−committed(H)− aborted(H). On the other hand, the set ofterminatedtransactions are those which have either committed or aborted and is denoted byterm(H) = committed(H)∪ aborted(H).

The relation between the events of transactions & histories is analogous to the relation between methods & transactions. We assume that for any transactionT in

txns(H),evts(T)is a subset ofevts(H)and<T is a subset of<H. Formally,h∀T ∈ txns(H) : (evts(T)⊆evts(H)) ∧(<T⊆<H)i.

We denote two historiesH1, H2 asequivalentif their events are the same, i.e., evts(H₁) = evts(H₂). A historyH is qualified to be well-formed if: (1) all the methods of a transactionT_iinHare totally ordered, i.e. a transaction invokes a method only after it receives a response of the previous method invoked by it (2)T_idoes not invoke any other method after it received anA response or aftertryC(ok)method. We only considerwell-formedhistories forOPT-MVOSTM.

A methodmij(j^thmethod of a transactionTi) in a historyHis said to beisolated oratomicif for any other eventepqr(r^thevent of methodmpq) belonging to some other methodmpqof transactionTpeitherepqroccurs before inv(mij)or after rsp(mij).

Sequential Histories:A historyH is said to besequential(term used in [12, 13]) if all the methods in it are complete and isolated. From now onwards, most of our discussion would relate to sequential histories.

Since in sequential histories all the methods are isolated, we treat each method as a whole without referring to itsinvandrspevents. For a sequential historyH, we construct thecompletionofH, denotedH, by insertingtryA_k(A)immediately after the last method of every transactionT_k ∈live(H). Since all the methods in a sequential history are complete, this definition only has to take care of completed transactions.

Consider a sequential historyH. Letmij(ht, k, v/nil)be the first method ofTiin Hoperating on the keykasH.f irstKeyM th(hht, ki, Ti), wheremijstands forj^th method ofi^thtransaction. For a methodmix(ht, k, v)which is not the first method onhht, kiofTiinH, we denote its previous method onkofTi asmij(ht, k, v) = H.prevKeyM th(mix, Ti).

Real-time Order and Serial Histories:Given a historyH,<Horders all the events inH. For two complete methodsmij, mpqinmethods(H), we denotemij≺^{M R}_H mpq

if rsp(mij)<Hinv(mpq). Here MR stands for method real-time order. It must be noted that all the methods of the same transaction are ordered. Similarly, for two transactions T_i, T_pinterm(H), we denote(T_i ≺^{T R}_H T_p)if(T_i.lastEvt <_H T_p.f irstEvt). Here TR stands for transactional real-time order.

We define a historyH asserial[14] ort-sequential[13] if all the transactions inH have terminated and can be totally ordered w.r.t≺T R, i.e. all the transactions execute one after the other without any interleaving. Intuitively, a historyHis serial if all its transactions can be isolated. Formally,h(His serial) =⇒ (∀Ti ∈txns(H) : (T_i ∈ term(H))∧(∀Ti, T_p ∈ txns(H) : (T_i ≺^{T R}_H T_p)∨(T_p ≺^{T R}_H T_i))i. Since all the methods within a transaction are ordered, a serial history is also sequential.

Valid Histories: A rv method (t deleteandt lookup)rvm_ij on keyk is valid if it returns the value updated by any of the previously committed transaction that updated keyk. A historyHis said to valid if all the rv methods of H are valid.

Legal Histories:We define thelegalityof rv methods on sequential histories which we use to define correctness criterion as opacity [8]. Consider a sequential historyHhaving a rv methodrvmij(ht, k, v)(withv6=null) asj^thmethod belonging to transactionT_i. We define thisrvmmethod to belegalif:

Rule 1 If thervmijis not the first method ofT_ito operate onhht, kiandm_ixis the pre- vious method ofT_ionhht, ki. Formally,rvmij6=H.f irstKeyM th(hht, ki, T_i)

∧(mix(ht, k, v⁰) = H.prevKeyM th(hht, ki, Ti)) (where v⁰ could be null).

Then,

(a) Ifmix(ht, k, v⁰)is at insertmethod thenv=v⁰. (b) Ifm_ix(ht, k, v⁰)is at lookupmethod thenv=v⁰. (c) Ifmix(ht, k, v⁰)is at deletemethod thenv=null.

In this case, we denotemixas the last update method ofrvmij, i.e., m_ix(ht, k, v⁰) =H.lastU pdt(rvm_ij(ht, k, v)).

Rule 2 Ifrvmijis the first method ofTito operate onhht, kiandvis not null. Formally, rvmij(ht, k, v) =H.f irstKeyM th(hht, ki, Ti)∧(v6=null). Then,

(a) There is at insertmethodt insertpq(ht, k, v)inmethods(H)such thatTp

committed beforervmij. Formally,h∃t insertpq(ht, k, v)∈methods(H) : tryC_p ≺^{M R}_H rvmiji.

(b) There is no other update methodupxy of a transactionTxoperating on hht, kiinmethods(H)such thatTxcommitted afterTpbut beforervmij. Formally,h@upxy(ht, k, v⁰⁰) ∈ methods(H) : tryC_p ≺^{M R}_H tryC_x ≺^{M R}_H rvmiji.

In this case, we denotetryC_pas the last update method ofrvmij, i.e.,tryC_p(ht, k, v)=

H.lastU pdt(rvmij(ht, k, v)).

Rule 3 Ifrvmij is the first method ofT_ito operate onhht, kiandvis null. Formally, rvmij(ht, k, v) =H.f irstKeyM th(hht, ki, T_i)∧(v=null). Then,

(a) There ist deletemethodt deletepq(ht, k, v⁰)inmethods(H)such thatTp

committed beforervmij. Formally,h∃t deletepq

(ht, k, v⁰)∈methods(H) :tryC_p≺^{M R}_H rvmiji. Herev⁰could be null.

(b) There is no other update methodupxy of a transactionTxoperating on hht, kiinmethods(H)such thatTxcommitted afterTpbut beforervmij. Formally,h@up_xy(ht, k, v⁰⁰) ∈ methods(H) : tryC_p ≺^{M R}_H tryC_x ≺^{M R}_H rvmiji.

In this case, we denotetryC_pas the last update method ofrvmij, i.e.,tryC_p(ht, k, v)

=H.lastU pdt(rvmij(ht, k, v)).

We assume that when a transactionTioperates on keykof a hash-tableht, the result of this method is stored inlocal logsofTi,txLogifor later methods to reuse. Thus, only the first rv method operating onhht, kiofTiaccesses the shared memory. The other rv methods ofTioperating onhht, kido not access the shared memory and they see the effect of the previous method from thelocal logs,txLog_i. This idea is utilized in Rule 1. With reference to Rule 2 and Rule 3, it is possible thatT_xcould have aborted beforervmij.

Coming to t insert methods, since at insert method always returns ok as they overwrite the node if already present therefore they always take effect on theht. Thus, we denote allt insertmethods as legal and only give legality definition for rv method.

We denote a sequential historyHaslegalorlinearizedif all itsrvmmethods are legal.

We formally prove the legality of the proposedOPT-MVOSTMsin Section 6.

Opacity:It is acorrectness-criteriafor STMs [8]. A sequential historyHis said to be opaque if there exists a serial historyS such that: (1)S is equivalent toH, i.e., evts(H) =evts(S)(2)Sis legal and (3)Srespects the transactional real-time order ofH, i.e.,≺^{T R}_H ⊆≺^{T R}_S .

Finally, we show that history generated by OPT-MVOSTMssatisfy correctness

criteria as opaque.

3. Graph Characterization of Opacity

To prove that an STM system satisfies opacity, it is useful to consider graph char- acterization of histories. In this section, we describe the graph characterization of Guerraoui and Kapalka [11] modified for sequential histories.

Consider a historyHwhich consists of multiple version for each t-object. The graph characterization uses the notion ofversion order. GivenH and a t-objectk, we define a version order forkas any (non-reflexive) total order on all the versions ofkever created by committed transactions inH. It must be noted that the version order may or may not be the same as the actual order in which the versions ofkare generated inH. A version order ofH, denoted as_His the union of the version orders of all the t-objects inH. Consider the historyH3as shown in Figure 3:lu1(kx,0, null), lu2(kx,0, null), lu1

(ky,0, null), lu3(kz,0, null), ins1(kx,1, v11), ins3(ky,3, v31), ins2(ky,2, v21), ins1(kz,1, v12), c1, c2, lu4(kx,1, v11), lu4(ky,2, v21), ins3(kz,3, v32), c3, lu4(kz,1, v12), lu5(kx,1, v11), lu6(ky,2, v21), c4, c5, c6. Using the notation that a committed transactionTiwrit- ing tokxcreates a versionkx,i, a possible version order forH3H3 is: hkx,0 kx,1i,hky,0ky,2ky,3i,hkz,0kz,1kz,3i.

T1

T2

T3

C1

T4

C3

C2

C4

T5

T6 C6

C5

lu2(kx,0, null) ins2(ky,2, v21)

lu3(kz,0, null) ins3(ky,3, v31) ins3(kz,3, v32)

lu4(kx,1, v11) lu4(ky,2, v21) lu4(kz,1, v12) lu5(kx,1, v11)

lu6(ky,2, v21) lu1(ky,0, null)

lu1(kx,0, null) ins1(kx,1, v11) ins1(kz,1, v12)

Figure 3: HistoryH3in time line view

We define the graph characterization based on a given version order. Consider a historyH and a version order. We then define a graph (called opacity graph) onH using, denoted asOP G(H,) = (V, E). The vertex setV consists of a vertex for

each transactionTiinH. The edges of the graph are of three kinds and are defined as follows:

1. rt(real-time) edges: If the commit ofT_i happens before beginning ofT_j inH, then there exist a real-time edge fromv_itov_j. We denote set of such edges as rt(H).

2. rvf(return value-from) edges: IfT_jinvokes rv method on keyk₁fromT_iwhich has already been committed inH, then there exists a return value-from edge fromvi tovj. If Ti is having upd method as insert on the same keyk1 then insi(k1,i, vi1)<H ci<H rvmj(k1,i, vi1). IfTiis having upd method as delete on the same keyk1thendeli(k1,i, null)<Hci<H rvmj(k1,i, null). We denote set of such edges asrvf(H).

3. mv(multi-version) edges: This is based on version order. Consider a triplet with successful methods asup_i(k1,i, u),rvmj(k1,i, u),up_k(k1,k, v), whereu 6= v.

As we can observe it fromrvmj(k_1,i, u),c_i <_H rvmj(k_1,i, u). ifk_1,i k_1,k then there exist a multi-version edge fromv_j tov_k. Otherwise (k_1,k k_1,i), there exist a multi-version edge fromv_k tov_i. We denote set of such edges as mv(H,).

We now show that if a version orderexists for a historyH such that it is acyclic, then His opaque.

mv rt

rt, rvf

rvf rvf

rt, rvf

rt, rvf rt

rt

rt rt

rt

rt, rvf rt

rt, rvf

T1

T2

T3

T4

T5

T6

T0

Figure 4:OP G(H3,_H3)

Using this construction, theOP G(H3,H3)for historyH3andH3is given above is shown in Figure 4. The edges are annotated. The only mv edge fromT4to T3is because of t-objectsky, kz.T4lookups valuev12forkzfromT1whereasT3also insertsv₃₂tok_zand commits beforelu₄(k_z,1, v₁₂).

Given a historyHand a version order, consider the graphOP G(H,). While considering thertedges in this graph, we only consider the real-time relation ofH and notH. It can be seen that≺^RT_H ⊆≺^RT

H but with this assumption,rt(H) =rt(H).

Hence, we get the following property,

Property 1. The graphsOP G(H,)andOP G(H,)are the same for any history Hand.

Definition 1. For a t-sequential historyS, we define a version orderS as follows:

For two versionkx,i, kx,j created by committed transactions Ti, Tj inS,hkx,i S

kx,j ⇔Ti<S Tji.

Now we show the correctness of our graph characterization using the following lemmas and theorem.

Lemma 2. Consider a legal t-sequential historyS. Then the graphOP G(S,_S,) is acyclic.

Proof: We numerically order all the transactions inSby their real-time order by using a functionord. For two transactionsT_i, T_j, we defineord(T_i)< ord(T_j)⇔T_i<_S T_j. Let us analyze the edges ofOP G(S,_S,) one by one:

• rt edges: It can be seen that all the rt edges go from a lower ord transaction to a higher ord transaction.

• rvf edges: IfT_jlookupsk_xfromT_iinSthenT_iis a committed transaction with ord(T_i)< ord(T_j). Thus, all the rvf edges from a lower ord transaction to a higher ord transaction.

• mv edges: Consider a successful rv methodrvmj(kx, u)and a committed trans- actionTk writingvtokxwhereu6=v. Letcibervmj(kx, u)’s lastWrite. Thus,

up_i(kx,i, u)∈evts(Ti). Thus, we have thatord(Ti)< ord(Tj). Now there are two cases w.r.tTi: (1) Supposeord(Tk)< ord(Ti). We now have thatTkTi. In this case, the mv edge is fromTktoTi. (2) Supposeord(Ti)< ord(Tk)which implies thatT_i T_k. SinceSis legal, we get thatord(T_j)< ord(T_k). This case also implies that there is an edge fromord(T_j)toord(T_k). Hence, in this case as well the mv edges go from a transaction with lower ord to a transaction with higher ord.

Thus, in all the three cases the edges go from a lower ord transaction to higher ord transaction. This implies that the graph is acyclic.

Lemma 3. Consider two historiesH, H⁰that are equivalent to each other. Consider a version orderHon the t-objects created byH. The mv edgesmv(H,H)induced byH are the same inH andH⁰.

Proof: Since the histories are equivalent to each other, the version orderHis appli- cable to both of them. It can be seen that the mv edges depend only on events of the history and version order. It does not depend on the ordering of the events inH. Hence, the mv edges ofHandH⁰are equivalent to each other.

Using these lemmas, we prove the following theorem.

Theorem 4. A valid history H is opaque iff there exists a version orderHsuch that OP G(H,H)is acyclic.

Proof: (if part):Here we have a version orderHsuch thatGH =OP G(H,)is acyclic. Now we have to show thatHis opaque. Since theG_His acyclic, a topological sort can be obtained on all the vertices ofG_H. Using the topological sort, we can generate a t-sequential historyS. It can be seen thatSis equivalent toH. SinceSis obtained by a topological sort onG_Hwhich maintains the real-time edges ofH, it can be seen thatSrespects the rt order ofH, i.e≺^RT_H ⊆≺^RT_S .

Similarly, sinceGH maintains return value-from (rvf) order ofH, it can be seen that ifTj lookups kx fromTi inH then Ti terminates beforeluj(kx)andTj inS.

Thus, S is valid. Now it remains to be shown thatS is legal. We prove this using

contradiction. Assume that S is not legal. Thus, there is a successful rv method rvmj(kx, u)such that its lastWrite inSisck andTk updates valuev(6=u)tokx, i.e up_k(kx,k, v)∈evts(Tk). Further, we also have that there is a transactionTithat inserts utok_x, i.eup_i(k_x,i, u)∈ evts(T_i). SinceS is valid, as shown above, we have that T_i ≺^RT_S T_k ≺^RT_S T_j.

Now in_H, ifk_x,kH k_x,ithen there is an edge fromT_ktoT_iinG_H. Otherwise (k_x,iH k_x,k), there is an edge fromT_jtoT_k. Thus, in either case,T_kcan not be in betweenTiandTjinScontradicting our assumption. This shows thatSis legal.

(Only if part):Here we are given thatHis opaque and we have to show that there exists a version ordersuch thatGH =OP G(H,)(=OP G(H,), Property 1) is acyclic. SinceH is opaque there exists a legal t-sequential historyS equivalent toH such that it respects real-time order ofH. Now, we define a version order for S,S as in Definition 1. Since the S is equivalent toH,S is applicable to H as well. From Lemma 2, we get thatG_S =OP G(S,S)is acyclic. Now consider G_H =OP G(H,S). The vertices ofG_Hare the same asG_S. Coming to the edges,

• rt edges: We have thatSrespects real-time order ofH, i.e≺^RT_H ⊆≺^RT_S . Hence, all the rt edges ofHare a subset ofS.

• rvf edges: SinceHandSare equivalent, the return value-from relation ofHand Sare the same. Hence, the rvf edges are the same inG_HandG_S.

• mv edges: Since the version-order and the operations of theH andSare the same, from Lemma 3 it can be seen thatH andShave the same mv edges as well.

Thus, the graphGHis a subgraph ofGS. Since we already know thatGSis acyclic from Lemma 2, we get thatGHis also acyclic.

4. OPT-MVOSTMsDesign and Data Structure

This section describes the design and data structure of optimizedMVOSTMs(or OPT-MVOSTMs). Here, we propose hash-table and list basedOPT-MVOSTMsasOPT- HT-MVOSTMandOPT-list-MVOSTMrespectively. OPT-MVOSTMsare generic for

1 2 3

(a) Underlying hash−table (b) Data structure for maintaining versions

vl(version list)

6 8 11

ts

ts val rvl maxrvlvnext

v0 11

0

15 19 21 ts

−∞ k2 k4 k6 k7 +∞ k2 . . .

B

key lock marked vl nnext T /F

rvl(return value list) 14

ts val rvl maxrvlvnext

21 . . .

v2

Figure 5: OptimizedHT-MVOSTMdesign

other data structure as well.OPT-HT-MVOSTMis a hash-table basedOPT-MVOSTM that explores the idea of multiple versions inOSTMs for hash-table object to achieve greater concurrency. The design ofOPT-HT-MVOSTMis similar toHT-MVOSTM[1]

consisting ofB buckets. All the keys of the hash-table in the rangeK are statically allocated to one of these buckets.

Each bucket consists of linked-list of nodes along with two sentinel nodesheadand tailwith values -∞and +∞respectively. The structure of each node is ashkey, lock, marked, vl, nnexti. Thekeyis a unique value from the set of all keysK. All the nodes are stored in increasing order in each bucket as shown in Figure 5 (a), similar to any linked-list based concurrent set implementation [7, 15]. In the rest of the document, we use the terms key and node interchangeably. To perform any operation on a key, the correspondinglockis acquired. markedis a boolean field which represents whether the key is deleted or not. The deletion is performed in a lazy manner similar to the concurrent linked-lists structure [7]. If themarkedfield is true then key corresponding to the node has been logically deleted; otherwise, it is present. Thevl field of the node points to the version list (shown in Figure 5 (b)) which stores multiple versions corresponding to the key. The last field of the node isnnextwhich stores the address of the next node. It can be seen that the list of keys in a bucket is as an extension of lazy-list[7]. Given a nodenin the linked-list of bucketB with keyk, we denote its fields asn.key(ork.key), n.lock(ork.lock), n.marked(ork.marked), n.vl(or k.vl), n.nnext(ork.nnext).

The structure of each version in thevlof a keykishts, val, rvl, maxrvl, vnexti as shown in Figure 5 (b). The fieldtsdenotes the unique timestamp of the version. In

our algorithm, every transaction is assigned a unique timestamp when it begins which is also itsid. Thustsof this version is the timestamp of the transaction that created it. All the versions in thevlofkare sorted byts. Since the timestamps are unique, we denote a version,verof a nodenwith keykhavingts jasn.vl[j].verork.vl[j].ver. The cor- responding fields in the version ask.vl[j].ts, k.vl[j].val, k.vl[j].rvl, k.vl[j].max_rvl, k.vl[j].vnext.

The fieldvalcontains the value updated by an update transaction. If this version is created by an insert methodt inserti(ht, k, v)by transactionTi, thenvalwill bev. On the other hand, if the method ist deletei(ht, k, v)thenvalwill benull. In this case, as per the algorithm, the node of keykwill also be marked.OPT-HT-MVOSTMalgorithm does not immediately physically remove deleted keys from the hash-table. The need for this is explained below. Thus an rv method (t deleteort lookup) on keykcan return nullwhen it does not find the key or encounters anullvalue fork.

Thervlfield stands forreturn value listwhich is a list of all the transactions that executed rv method on this version, i.e., those transactions which returnedval. The first optimization inOPT-HT-MVOSTMto reduce the traversal time ofrvl, we have used max_rvlwhich contains the maximumtsof the transaction that executed rv method on this version. The fieldvnextpoints to the next available version of that key.

In order to increase the efficiency and utilize the memory properly, We propose two variants ofOPT-HT-MVOSTMas follows: First, we apply garbage collection (or GC) on the versions and proposeOPT-HT-MVOSTM-GC. It maintains unbounded versions invl (the length of the list) while deleting the unwanted versions using garbage collection scheme. Second, we proposeOPT-HT-KOSTMwhich maintains the bounded number of versions such asKand improves the efficiency further. Whenever a new version veris created and is about to be added tovl, the length ofvlis checked. If the length becomes greater thanK, the version with lowestts(i.e., the oldest) is replaced with the new versionverand thus maintaining the length back toK.

We proposeOPT-list-MVOSTMswhile considering the bucket size as 1 inOPT-HT- MVOSTM. Along with this, we propose two variants ofOPT-list-MVOSTMasOPT-list- MVOSTM-GCandOPT-list-KOSTMwhich applies the garbage collection scheme in unbounded versions and boundedKversions for list based object respectively similar

k4 k8

−∞ k2 k11 +∞

2 1

B

Figure 6: Searchingk11overlazy-list

k8

−∞

k2 k4

k11 +∞

2 1

B

Figure 7: Searchingk11overlazyrb-list

toOPT-HT-MVOSTM.

Marked Version Nodes: OPT-HT-MVOSTMstores keys even after they have been deleted (the version of the nodes which havemarkedfield as true). This is because some other concurrent transactions could read from a different version of this key and not thenullvalue inserted by the deleting transaction. Consider for instance the transaction T₁performinglu₁(ht, k₂, v₀)as shown in Figure 2 (b). Due to the presence of previous versionv₀,OPT-HT-MVOSTMreturns this earlier versionv₀forlu₁(ht, k₂, v₀)method.

Whereas, it is not possible forHT-OSTMto return the versionv₀becausek₁has been removed from the system by delete method of higher timestamp transactionT2than T1. In that case,T1would have to be aborted. Thus as explained in Section 1, storing multiple versions increases the concurrency.

To store deleted keys along with the live keys (or unmarked node) in a lazy-list will increase the traversal time to access unmarked nodes. Consider Figure 6, in which there are four keyshk2, k4, k8, k11ipresent in the list. Herehk2, k4, k8iare marked (or deleted) nodes whilek₁₁is unmarked. Now, consider accessing the keyk₁₁by OPT-HT-MVOSTMas a part of one of its methods. ThenOPT-HT-MVOSTMwould have to unnecessarily traverse the marked nodes to reach keyk₁₁.

This motivated us to modify the lazy-list structure of nodes in each bucket to form a skip list based on red and blue links. We denote it asred-blue lazy-listorlazyrb-list.

This idea was earlier explored by Peri et al. in developingOSTMs [6]. lazyrb-list consists of nodes with two links, red link (orRL) and blue link (orBL). The node which is not marked (or not deleted) are accessible from the head viaBL. While all the nodes including the marked ones can be accessed from the head viaRL. With this modification, let us consider the above example of accessing unmarked keyk11. It can be seen that k₁₁can be accessed much more quickly throughBLas shown in Figure 7. Using the idea oflazyrb-list, we have modified the structure of each node ashkey, lock, marked,

vl,RL,BLi. Further, for a bucketB, we denote its linked-list asB.lazyrb-list.

5. Working ofOPT-HT-MVOSTM

OPT-HT-MVOSTMexportst begin,t insert,t delete,t lookup, andtryCmethods as explained in Section 2. Among themt delete,t lookupare return-value methods (or rv methods) whilet insert,t deleteare update methods (or upd methods). We treat t deleteas both rv method as well as upd method. The rv methods return the current value of the key. The upd methods, update to the keys are first noted down in the local log,txLog. Then in thetryCmethod after successful validations of these updates are transferred to the shared memory. We now explain the working of each method as follows:

t begin():A thread invokes a new transactionT_iusing this method. The transactionT_i local logtxLog_iis initialized at Line 2. This method returns a unique id to the invoking thread by incrementing an atomic counter at Line 3. This unique id is also the timestamp of the transactionTi. For convenience, we use the notation thatiis the timestamp (or id) of the transactionTi.

Algorithm 1t begin(): It provides the local log and unique id to each transaction.

1:proceduret begin()

2: txLog←new txLog(). .Initialize the local log of transaction

3: t id←get&inc(counter). .Get the unique transaction id (t id) while incrementing thecounteratomically

4: returnt id.

5:end procedure

rv methods: It can be eithert delete(ht, k, v)ort lookup(ht, k, v). Both these methods return the current value of keyk. Algorithm 2 gives the high level overview of these methods. First, the algorithm checks to see if the given key is already in the local log, txLogiofTi(Line 7). If the key is already there then the current rv method is not the first method onkand is a subsequent method ofTionk. So, we can return the value of kfrom thetxLogi.

If the key is not present in thetxLogi, thenOPT-HT-MVOSTMsearches into shared memory. Specifically, it searches the bucket to whichkbelongs to. Every key in the rangeK is statically allocated to one of theB buckets. So the algorithms search

forkin the corresponding bucket, sayBk to identify the appropriate location, i.e., identify the correctpredecessororpred andcurrentorcurrkeys in the lazyrb-list ofBk without acquiring any locks similar to the search in lazy-list [7]. Since each key has two links,RL and BL, the algorithm identifies four node references: two predand twocurraccording to red and blue links. They are stored in the form of an array withpreds[0]andcurrs[1]corresponding to blue links;preds[1]andcurrs[0]

corresponding to red links. If bothpreds[1]andcurrs[0]nodes are unmarked then the pred, currnodes of both red and blue links will be the same, i.e.,preds[0]=preds[1]

andcurrs[0]=currs[1]. Thus depending on the marking ofpred, currnodes, a total of two, three or four different nodes will be identified. Here, the search ensures that preds[0].key≤preds[1].key < k≤currs[0].key≤currs[1].key.

Next, the re-entrant locks on all thepred, currkeys are acquired in increasing order to avoid the deadlock. Then all thepred andcurrkeys are validated byrv - Validation()in Line 12 as follows: (1) Ifpredandcurrnodes of blue links are not marked, i.e, (¬preds[0].marked) && (¬currs[1].marked). (2) If the next links of both blue and redpred nodes point to the correctcurr nodes: (preds[0].BL = currs[1]) && (preds[1].RL=currs[0])at Line 74.

If any of these checks fail, then the algorithm retries to find the correctpredandcurr keys. It can be seen that the validation check is similar to the validation in concurrent lazy-list [7].

Next, we check ifkis inBk.lazyrb-list. Ifkis not inBk, then we create a new nodenforkas:hkey=k, lock=f alse, marked=true, vl=ver, nnext=φiand insert it intoBk.lazyrb-listsuch that it is accessible only viaRL. This node will have a single versionverashts= 0, val=null, rvl=i, max_rvl =i, vnext=φi. Here invoking transactionT_iis creating a version with timestamp0to ensure that rv methods of other transactions will never abort. As we have explained in Figure 2 (b) of Section 1, even afterT₂deletesk₂, the previous value ofv₀is still retained. Thus, whenT₁invokes luonk2after the delete onk2byT2,OPT-HT-MVOSTMwill returnv0(as previous value). Hence, each rv method will find a version to read while maintaining the infinite version corresponding to each keyk.markedfield sets to true because it access byRL only. Inrvlandmaxrvl,Tiadds the timestamp asiin it andvnextis initialized to

empty value. Sincevalis null and then, this version and the node are not technically inserted intoBk.lazyrb-list.

Ifkis inBk.lazyrb-listthen,kis the same ascurrs[0]orcurrs[1]or both. Let nbe the node ofkinB_k.lazyrb-list. We then find the version ofn,ver_j which has the timestampjsuch thatjhas the largest timestamp smaller thani(timestamp ofT_i).

Additover_j’srvl(Line 24). max_rvlmaintains the maximum timestamp among all rv methods read from this version at Line 26. Then release the locks, update the local logtxLogiin Line 29 and return the value stored inverj.valin Line 31.

Algorithm 2rv method:It can be eithert deletei(ht, k, v)ort lookup_i(ht, k, v)on key kthat maps to bucketBkof hash-tableht.

6:procedurerv methodi(ht, k, v)

7: if(k∈txLogi)then

8: Update the local log and returnval.

9: else

10: Search in lazyrb-list to identify thepreds[]andcurrs[]forkusingBLandRLin bucketBk.

11: Acquire the locks onpreds[]andcurrs[]in increasing order.

12: if(!rv V alidation())then

13: Release the locks and goto Line 10.

14: end if

15: if(k /∈ B_k.lazyrb-list)then

16: Create a new nodenwith keykas:hkey = k, lock = false, marked = true, vl = ver, nnext =φi.

17: /*Thevlconsists of a single elementverwithtsas 0*/

18: Create the versionveras:hts= 0, val=null, rvl=i, max_rvl=i, vnext=φi.

19: InsertnintoB_k.lazyrb-listsuch that it is accessible only viaRLs. . nis marked

20: Release the locks; update thetxLog_iwithk.

21: returnnull.

22: end if

23: Identify the versionver_jwithts=jsuch thatjis the largest timestamp smaller thani.

24: Addiinto thervlofver_j.

25: if(ver_j.max_rvl< i)then

26: Setver_j.max_rvltoi.

27: end if

28: retV al=verj.val.

29: Release the locks; update thetxLogiwithkandretV al.

30: end if

31: returnretV al.

32:end procedure

t insert(): This is another optimization done inOPT-HT-MVOSTMsto identify the early abort which prevents the work done by aborted transactions and saves time. The actual effect of thet insert() comes after the successful tryC method. First, t insert() searches the keykin the local log,txLogiofTiat Line 34. Ifkdoes not exist in thetxLogi

then it identifies the appropriate location (predandcurr) of keykusingBLandRL (Line 35) in the lazyrb-list ofBk without acquiring any locks similar to rv method explained above.

2 2 0 null

T2 C2

l2(ht, k5, null) T2 C2

l2(ht, k5, null)

T1

T1

tryC A1 i1(ht, k5, Abort)

T1 A1

i1(ht, k5, Abort) k5

vnext val maxrvl

ts rvl

. . .

(c) Underlying Data structure(DS) a) Delayed validation in tryC b) Early Validation in t insert()

Figure 8: Advantage of early validation in t insert()

Next, it acquires the re-entrant locks on all thepredandcurrkeys in increasing order. After that, all thepredandcurrkeys are validated bytryC Validationin Line 37 as follows: (1) It does therv Validation()as explained above in the rv method. (2) If keykexists in theBk.lazyrb-listand letnas a node ofk. Then algorithm identifies the version ofn,verjwhich has the timestampjsuch thatjhas the largest timestamp smaller thani(timestamp ofT_i) at Line 85. Ifmax_rvlofver_jis greater than timestamp iat Line 86 then it returnsAbortin Line 38.

tryC Validation()int insert() identifies the early abort of invalid transaction. The advantage of doing the early validation to save the significant computation of long running transaction which will abort in the future. Consider Figure 8 where two transactionT1andT2working on keyk5. In Figure 8 (a),T1aborts in tryC (delayed validation) because higher timestampT2committed. But in Figure 8 (b),T1validates the t insert() instantly by looking into themaxrvlofk5as shown in Figure 8 (c) and save its computation and returns abort.

Algorithm 3t insert():Actual insertion happens in the tryC.

33:proceduret insert()

34: if(k /∈txLog_i)then

35: Search in lazyrb-list to identify thepreds[]andcurrs[]forkusingBLandRLin bucketB_k.

36: Acquire the locks onpreds[]andcurrs[]in increasing order.

37: if(!tryC V alidation())then

38: returnAbort. .Release the locks

39: end if

40: Release the locks.

41: else

42: Update the local log.

43: end if

44:end procedure

upd methods: It can be eithert insert(ht, k, v)ort delete(ht, k, v). Both the methods create a version corresponding to the keyk. The actual effect oft insertandt deletein shared memory will take place intryC. Algorithm 4 represents the high level overview