The elements in the list are sorted by their keys corresponding to the sets of implementations discussed in [8, Chapter 9]. Our OSTM ensures that the sequence of operations is composed driven by the legality and conflict concept and correctness proofs of the generated stories. Each update event transfers the global state of the system, leading to a new global state.
Hereevts(T) is all the read/write events at layer-0 of the transaction. If a node is present in BL, it will store the location (found via BL) of the node corresponding to the key in the local logo, otherwise it will search through RL within the same location identified by traversing BL. Therefore, we maintain max_ts_lookup(ht, k), max_ts_insert(ht, k), and max_ts_delete(ht, k), which represent the timestamp of the last committed transaction that was performed t_lookup(ht, k), t_insert(ht, k), and t_delete, respectively (ht, k). .max_ts,nodeandll_entry form part of meta information for OSTM. T1 and T2 are trying to access the k5 key, here1, s2 and 3 represent the current state of the lazy skip list. Figure 10(i)(c) is lazyskip list before adding afk5 and Figure 10(i)(d) is lazyskip list state after adding. 5 Correctness of OSTMs 6 Related Work OSTM combines the extensible abstraction and ease of programming from STMs with our efficient mechanism for achieving composability using object-level semantics. Our prototype implementation of OSTM shows significant performance gains over read/write STM for a simple SET application (in Appendix E). We tested it only to verify the performance improvement of object level transaction compared to read/write only transactions. In PPoPP '05: Proceedings of the Tenth ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, pages 48–60, New York, NY, USA, 2005. In Proceedings of the 13th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, pages 207–216. In Proceedings of the 12th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, pages 68–78. InPODC '95: Proceedings of the Fourteenth Annual ACM Symposium on Principles of Distributed Computing, pages 204–213, New York, NY, USA, 1995. In Proceedings of the Eleventh ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, PPoPP ' 06 , pages 129–136, New York, NY, USA, 2006. A history is said to be sequential (term used in [12, 13]) or linearized[11] if all the methods in it are complete and isolated. Since all the methods in sequential histories are isolated, we treat each method as a whole without referring to its inv and rsp events. Since all the methods in a sequential history are complete, this definition only needs to take care of completing transactions. Since all the methods of a transaction are sequential and ordered, we can clearly identify the first method of Tion keyk. The leaves of the tree denoted as layer-0 consist of read, write primitives on atomic objects. For simplicity, we have ignored the inv&b events at level-0 of the tree. The level-1 of the tree consists of methods invoked by the transaction. In the transaction shown in Figure 13, level-1 consists of the t_lookupandt_deletemethods methods that operate on the lazy skip list, as also shown in Figure 1(i). We assume that if a transaction has invoked a method, then it doesn't invoke a new method until it gets a response from the previous one. Legal history: If rv_method is not the first transaction method on any key, it will return the same value as the previous method of the same transaction on the same key. Figure 16STM_lookup() is returning the same value as the previous method of the same transaction on the same key. Iffrv_methodis the first method of a transaction on any key and value is not null, then the closest previous method of the committed transaction must be entered on the same key. In Figure 17, the closest previous method for Luij(ht, k, vp) of transaction same keykisInspq(ht, k, vp) of transaction Tp. So Luij(ht, k, vp) will return the same value inserted by Inspq(ht, k, vp) and no other transaction_method_upd_method can exist on the same key between Tp and Ti. Figure 17STM_lookup() returns the same value as the previous closest conflicting method of the confirmed transaction. Figure 18STM_lookup() returns the same value as the previous closest conflicting method of the confirmed transaction. B Optimizations There can be the following cases: if the node is present in RL and should be inserted in BL: such a case means that lslIns(preds[] ↓,currs[] ↓, ) is called in the execution phase inupd_method for the corresponding STM_insert() in the registry local represented by the block from line 2 to line 5. Thus the node is now reachable from BLAlso. if the node is meant to be inserted only in RL: This means that the node is not present in the lazyskip list at all and should be inserted for the first time. Such a case can be called from the rv_method offrv_method execution phase, if rv_method is the first method of its transaction. In line 9 and line 10, the RL field of thenode is updated tocurrs[0] and the RLfield of thepreds[1] is modified to point to the thenode respectively. if the node is intended to be inserted in BL: In such a case, it may happen that the node is already present in the RL (already covered by line 2 to line 5), or the node is not present at all. The later case is depicted in Lines 11 to 16, which create a new node and add the node in both RL and BL. Note that the order of insertion is important, since the lazyskip list can be simultaneously accessed by other transactions since traversal is locked free. It simply sets the checked field of the node to be deleted (currs[1]) and changes BLofpreds[1]tocurrs[0] as shown in line 2 and line 3 i. This is done by linearly traversing the log and finding the entry that matches the key. If the calling method is the first transaction method for thekeythenfindInLLreturn true because it would not find any entry in the transaction log that matches the key. Since we think there can be multiple objects (scatter table), so we need to find a unique hobj_id, keyipair (see line 5). Each transaction is assigned a unique timestamp inSTM_begin() method using a shared counter that is always incremented atomically. Let's assume, a node corresponding to the key is already the part of underlyingRL that has a timestamp ofm1asT1 of observation 41. Let saym2ofT2will perform on that node by observing the code at line 6 of toValidation() method of Algo 12, if TS (T2) Therefore, the node corresponding to the key,max_tsfield should be updated in ascending order of TS values. Induction hypothesis: Let's say up to k events that change the max_ts field of a node associated with a key, always in increasing TS value. Lines 26, 30 and 35 of the STM_delete() method of Algo 8: Observing the code, line 18 of the STM_delete() method of Algo 8 first invokes the method of Algo 1 to find the node corresponding to the key. Inside the thelslSearch() method of Algo 1, it will do the Validation() method of Algo 12, if(curr.key=key). By the induction hypothesis, the node corresponding to the key is already the part of the underlying RL that has a timestamp ofmkofTk from Observation 41. Let's say semk+1ofTk+1 wants to execute on that node, observing the code in line 6 of the Validate() method of Algo 12, if TS(Tk+1) Lines 18, 22, and 27 of the STM_lookup() method of alga 3: By observing the code, line 12 of the STM_lookup() method of alga 3 first calls the lslSearch() method of alga 1 to find the node corresponding to the key. From the induction hypothesis, the node corresponding to the key is already part of the underlying RL, which has timestamp mk as Tk from observation 41. From Lemma 9 and Lemma 14, we have that the nodes in the underlying data structure are in ascending order of their keys, so it has the key on which the operation operates, a unique location in the underlying data structure from Corollary 11. Now a similar tomi has an effect on the same node represented by keyk (from Observation 6 & Corollary 11) and from Observation 13 we know that the node corresponding to the keyki is still reachable viaRL. To succeed in Algo 12, TS(Tj)>curr.max_ts.mi() must evaluate to true from Corollary 43. The conflict graph construction therefore shows that (CG(H¯)=CG(H)) is a subgraph of CG (S). A legal history H is co-opaque if CG(H) is acyclic. Only if) If H is co-opaque and legal, then CG(H) is acyclic: Since H is co-opaque, there exists a legal t-sequential history S equivalent to H¯ and S respects≺RTH and≺COH (from the definition 1). So we can perform a topological sort on the vertices of the graph and obtain a sequential order. Since any two operations related to the conflict relation in S are also related to ≺COH¯ , we obtain.
7 Conclusion and Future Work
A Appendix
C Pseudocode
D Proof Sketch of OSTMs D.1 Operational Level
Transactional Level
E Preliminary results of OSTM
