A Fast Contention-Friendly Binary Search Tree∗

Tyler CrainINRIA

Vincent GramoliNICTA and University of Sydney

Michel RaynalInstitut Universitaire de France and Universite de Rennes

Abstract

This paper presents a fast concurrent binary search treealgorithm. To achieve high performance under contention,the algorithm divides update operations within an eagerabstract access that returns rapidly for efficiency reasonand a lazy structural adaptation that may be postponed todiminish contention. To achieve high performance un-der read-only workloads, it features a rebalancing mech-anism and guarantees that read-only operations search-ing for an element execute lock-free.

We evaluate the contention-friendly binary search treeusing Synchrobench, a benchmark suite to compare syn-chronization techniques. More specifically, we compareits performance against five state-of-the-art binary searchtrees that use locks, transactions or compare-and-swapfor synchronization on Intel Xeon, AMD Opteron andOracle SPARC. Our results show that our tree is moreefficient than other trees and double the throughput ofexisting lock-based trees under high contention.

Keywords: Binary tree, Concurrent data structures, Effi-cient implementation.

1 Introduction

Today’s processors tend to embed more and more cores.Concurrent data structures, which implement popularabstractions such as key-value stores [28], are thus be-coming a bottleneck building block of a wide variety ofconcurrent applications. Maintaining the invariants ofsuch structures, like the balance of a tree, induces con-tention. This is especially visible when using speculativesynchronization techniques as it boils down to restart-ing operations [10]. In this paper we describe how to

∗This paper is an extended version of a draft paper that ap-peared at the International Conference on Parallel Processing (Euro-Par 2013) [11] Among other improvements, it presents an experimentalevaluation on two other platforms and a comparison with four otherconcurrent binary search trees algorithms from the literature.

cope with the contention problem when it affects a non-speculative technique.

As a widely used and studied data structure in thesequential context, binary trees provide logarithmic ac-cess time complexity given that they are balanced, mean-ing that among all downward paths from the root toa leaf, the length of the shortest path is not far apartthe length of the longest path. Upon tree update, if theheight difference exceeds a given threshold, the struc-tural invariant is broken and a rebalancing is triggeredto restructure accordingly. This threshold depends onthe considered algorithm: AVL trees [1] do not toleratethe longest length to exceed the shortest by 2 whereasred-black trees [2] tolerate the longest to be twice theshortest, thus restructuring less frequently. Yet in bothcases the restructuring is triggered immediately whenthe threshold is reached to hide the imbalance from fur-ther operations. In a concurrent context, slightly weak-ened balance requirements have been suggested [4], butthey still require immediate restructuring as part of up-date operations to the abstractions.

We introduce the contention-friendly tree as a tree thattransiently breaks its balance structural invariant with-out hampering the abstraction consistency in order toreduce contention and speed up concurrent operationsthat access (or modify) the abstraction. More specifi-cally, we propose a partially internal binary search treedata structure decoupling the operations that modify theabstraction (we call these abstract operations) from oper-ations that modify the tree structure itself but not theabstraction (we call these structural operations). An ab-stract operation either searches for, logically deletes, orinserts an element from the abstraction where in certaincases the insertion might also modify the tree structure.Separately, some structural operations rebalance the treeby executing a distributed rotation mechanism as wellas physically removing nodes that have been logicallydeleted.

We evaluate the performance of our algorithmagainst various data structures on three multicore plat-forms using Synchrobench [17]. First, we compare the

1

performance against the previous practical binary searchtree [7]. Although both algorithms are lock-based bi-nary search trees, ours speeds up the other by 2.2×. Sec-ond, we evaluate the performance of a lock-free binarysearch tree [14] that uses exclusively compare-and-swapand the performance of a more recent binary search treethat offers lock-free contains operations (just like ours)and decouples similarly but without logically deletingnodes. Finally, we tested the transaction-based trees: theconcurrent red-black tree from Oracle and a port in Javaof the speculation-friendly tree [10]. In various settingsthe contention-friendly tree outperforms the five othertrees.

More specifically, we evaluated our algorithm onAMD Opteron, Oracle SPARC and Intel Xeon, againststate-of-the-art binary search tree implementations. Theformer architecture is a machine of 8 processors eachrunning 8 hardware threads at 1.2GHz while the latter isan AMD machine running 64 cores at 1.4GHz. On botharchitectures, the contention-friendly binary search treeoutperforms other trees at only 10% updates.

Roadmap. We present the related work in Section 2.We describe our methodology in Section 3 and thecontention-friendly tree in Section 4, and discuss our al-gorithm correctness in Section 5. We compare the perfor-mance of the contention-friendly tree against five othertree data structures synchronised with locks, compare-and-swap and transactions in Section 6. Finally, we con-clude in Section 7.

2 Related Work

On the one hand, the decoupling of update and rebalanc-ing dates back from the 70’s [19] and was exclusively ap-plied to trees, including B-trees [3], {2,3}-trees [25], AVLtrees [26] and red-black trees [32] (resulting in largelystudied chromatic trees [5, 33] whose operations cannotreturn before reaching a leaf) and more recently to skiplists [12,13]. On the other hand, the decoupling of the re-movals in logical and physical phases is more recent [30]but was applied to various structures: various linkedlists [18, 20, 21, 30], hash tables [29], skip lists [16], binarysearch trees [6, 10, 14] and lazy lists [23]. Our solutiongeneralizes both kinds of decoupling by distinguishingan abstract update from a structural modification.

We have recently observed the performance bene-fit of decoupling accesses while preserving atomicity.Our recent speculation-friendly tree splits updates intoseparate transactions to avoid a conflict with a rotationfrom rolling back the preceding insertion/removal [10].While it benefits from the reusability and efficiency ofelastic transactions [15], it suffers from the overhead of

bookkeeping accesses with software transactional mem-ory. The goal was to bound the asymptotic step com-plexity of speculative accesses to make it comparableto the complexity of pessimistic lock-based ones. Al-though this complexity is low in pessimistic executions,our result shows that the performance of a lock-basedbinary search tree greatly benefits from this decoupling.In Section 6, we show that a Java port of our speculation-friendly tree is significantly slower than the contention-friendly tree.

There exist several tree data structures that exploitlocks for synchronization. The practical lock-based treeexploits features of relaxed transactional memory mod-els to achieve high concurrency [7]. The implementationof this algorithm is written in Scala, which allowed usto use it as the baseline in our experiments. A key op-timization of this tree distinguishes whether a modifica-tion at some node i grows or shrinks the subtree rootedin i. A conflict involving a growth could be ignored asno descendants are removed and a search preempted atnode i will safely resume in the resulting subtree. Wecompare the performance of the original implementationto our tree in Section 6.

Lock-free trees are interesting to make sure that thesystem always makes progress whereas lock-based treesdo not prevent threads from blocking, which can beproblematic in a model where cores can fail. A lock-free binary search tree was proposed [14] by using ex-clusively single-word compare-and-swap (CAS) for syn-chronization. Unfortunately, this tree cannot be rotated.Section 6 depicts its performance under balanced work-loads. A more recent lock-free binary search trees wasproposed [31], unfortunately, we are not aware of anyJava-based implementation.

3 Overview

In this section, we give an overview of the Contention-Friendly (CF) methodology by describing how to writecontention-friendly data structures as we did to designa lock-free CF skip-list [9, 12]. The next section describeshow this is done for the binary search tree.

The CF methodology aims at modifying the imple-mentation of existing data structures using two simplerules without relaxing their correctness. The correct-ness criterion ensured here is linearizability [24]. Thedata structures considered are search structures becausethey organize a set of items, referred to as elements, ina way that allows to retrieve the unique position of anelement in the structure given its value. The typicalabstraction implemented by such structures is a collec-tion of elements that can be specialized into various sub-abstractions like a set (without duplicates) or a map (that

2

maps each element to some value). We consider insert,delete and contains operations that, respectively, insertsa new element associated to a given value, removes theelement associated to a given value or leaves the struc-ture unchanged if no such element is present, and re-turns the element associated to a given value or⊥ if suchan element is absent. Both inserts and deletes are con-sidered updates, even though they may not modify thestructure.

The key rule of our methodology is to decouple eachupdate into an eager abstract modification and a lazy struc-tural adaptation. The secondary rule is to make the re-moval of nodes selective and tentatively affect the lessloaded nodes of the data structure. These rules induceslight changes to the original data structures. that re-sult in a corresponding data structure that we denote us-ing the contention-friendly adjective to differentiate themfrom their original counterpart.

3.1 Eager abstract modification

Existing search structures rely on strict invariants toguarantee their big-oh (asymptotic) complexity. Eachtime the structure gets updated, the invariant is checkedand the structure is accordingly adapted as part of thesame operation. While the update may affect a smallsub-part of the abstraction, its associated restructuringcan be a global modification that potentially conflictswith any concurrent update, thus increasing contention.

The CF methodology aims at minimizing such con-tention by returning eagerly the modifications of the up-date operation that make the changes to the abstractionvisible. By returning eagerly, each individual processcan move on to the next operation prior to adapting thestructure. It is noteworthy that executing multiple ab-stract modifications without adapting the structure doesno longer guarantee the asymptotic complexity of the ac-cesses, yet, as mentioned in the Introduction, such com-plexity may not be the predominant factor in contendedexecutions.

A second advantage is that removing the structuraladaption from the abstract modification makes the costof each operation more predictable as operations sharesimilar costs and create similar amount of contention.More importantly the completion of the abstract oper-ation does not depend on the structural adaptation (likethey do in existing algorithms), so the structural adap-tation can be performed differently, for example, usingglobal information or being performed by separate, un-used resources of the system.

3.2 Lazy structural adaptation

The purpose of decoupling the structural adaptationfrom the preceding abstract modification is to enableits postponing (by, for example, dedicating a separatethread to this task, performing adaptations when ob-served to be necessary), hence the term “lazy” structuraladaptation. The main intuition here is that this structuraladaptation is intended to ensure the big-oh complexityrather than to ensure correctness of the state of the ab-straction. Therefore the linearization point of the updateoperation belongs to the execution of the abstract modifi-cation and not the structural adaptation and postponingthe structural adaptation does not change the effective-ness of operations.

This postponing has several advantages whoseprominent one is to enable merging of multiple adapta-tions in one simplified step. Only one adaptation mightbe necessary for several abstract modifications and mini-mizing the number of adaptations decreases accordinglythe induced contention. Furthermore, several adapta-tions can compensate each other as the combination oftwo restructuring can be idempotent. For example, aleft rotation executing before a right rotation at the samenode may lead back to the initial state and executing theleft rotation lazily makes it possible to identify that exe-cuting these rotations is useless. Following this, insteadof performing rotations as a string of updates as part of asingle abstract operation, each rotation is performed sep-arately as a single local operation, using the most up todate balance information.

Although the structural adaptation might be exe-cuted in a distributed fashion, by each individual up-dater thread, one can consider centralizing it at one dedi-cated thread. Since these data structures are designed forarchitectures that use many cores, performing the struc-tural adaptation on a dedicated single separate threadleverages hardware resources that might otherwise beleft idle.

Selective removal. In addition to decoupling level ad-justments, removals are preformed selectively. A nodethat is deleted is not removed instantaneously but ismarked as deleted. The structural adaptation then se-lects among these marked nodes those that are suit-able for removal, i.e., whose removal would not inducehigh contention. This selection is important to limit con-tention. Removing a frequently accessed node requireslocking or invalidating a larger portion of the structure.Removing such a node is likely to cause much more con-tention than removing a less frequently accessed one.In order to prevent this, only nodes that are markedas deleted and have at least one of their children as anempty subtree are removed. Marked deleted nodes can

3

then be added back into the abstraction by simply un-marking them during an insert operation. This leads toless contention, but also means that certain nodes thatare marked as deleted may not be removed. In similar,partially external/internal trees, it has already been ob-served that only removing such nodes [10], [7] results ina similar sized structure as existing algorithms. How-ever, it is difficult to bound the number of marked nodesunder peak contention: we could imagine a large num-ber of threads marking all elements simultaneously, re-sulting in an abstraction of size 0 while the structure con-tains some logically deleted nodes.

4 The Contention-Friendly Tree

The CF tree is a lock-based concurrent binary search treeimplementing classic insert/delete/contains operations.Its structure is similar to an AVL tree except that it vi-olates the depth invariant of the AVL tree under con-tention. Each of its nodes contains the following fields:a key k, pointers ` and r to the left and right child nodes,a lock field, a del flag indicating if the node has been log-ically deleted, a rem flag indicating if the node has beenphysically removed, and the integers left-h, right-h andlocal-h storing the estimated height of the node and itssubtrees used in order to decide when to perform rota-tions.

This section will now describe the CF tree algorithmby first describing three specific CF modifications that re-duce contention during traversal, followed by a descrip-tion of the CF abstract operations.

4.1 Avoiding contention during traversal

Each abstract operation of a tree is expected to traverseO(logn) nodes when there is no contention. During anupdate operation, once the traversal is finished a singlenode is then modified in order to update the abstraction.In the case of delete, this means setting the del flag totrue, or in the case of insert changing the child pointer ofa node to point to a newly allocated node (or unmarkingthe del flag in case the node exists in the tree). Given then,that the traversal is the longest part of the operation, theCF tree algorithm tries to avoid here, as often as possi-ble, producing contention. Many concurrent data struc-tures use synchronization during traversal even whenthe traversal does not update the structure. For exam-ple, performing hand-over-hand locking in a tree helpsensure that the traversal remains on track during a con-current rotation [7], or, using optimistic strategy (suchas transactional memory), validation is done during thetraversal, risking the operation to restart in the case ofconcurrent modifications [22, 23, 34].

4.2 Physical removal

As previously mentioned, the algorithm attempts to re-move only nodes whose removal incurs the least con-tention. Specifically, removing a node n with a subtreeat each child requires finding its successor node s in oneof its subtrees, then replacing n with s. Therefore pre-cautions must be taken (such as locking all the nodes)in order to ensure any concurrent traversal taking placeon the path from n to s does not violate linearizability.Instead of creating contention by removing such nodes,they are left as logically deleted in the CF tree; to be re-moved later if one of their subtrees becomes empty, or tobe unmarked if a later insert operation on the same nodeoccurs.

In the CF tree, nodes that are logically deleted andhave less than two child subtrees are physically removedlazily (cf. Algorithm 1). Since we do not want to use syn-chronization during traversal these removals are doneslightly differently than by just unlinking the node. Theoperation starts by locking the node n to be removed andits parent p (line 6). Following this, the appropriate childpointer of p is then updated (lines 12-13), effectively re-moving n from the tree. Additionally, before the locksare released, both of n’s left and right pointers are mod-ified to point back to p and the rem flag of n is set to true(lines 14-15). These additional modifications allow con-current abstract operations to keep traversing safely asthey will then travel back to p before continuing theirtraversal, much like would be done in a solution thatuses backtracking.

4.3 Rotations

Rotations are performed to rebalance the tree so thattraversals execute in logarithmic time in the number ofelements present in the abstraction once contention de-creases. As described in Section 3, the CF tree uses lo-calized rotations in order to minimize conflicts. Meth-ods for performing localized rotation operations in thebinary trees have already been examined and proposedin several works such as [4]. The main concept used hereis to propagate the balance information from a leaf tothe root. When a node has a ⊥ child pointer then thenode must know that this subtree has height 0 (the esti-mated heights of a node’s subtrees are stored in the inte-gers left-h and right-h). This information is then prop-agated upwards by sending the height of the child tothe parent, where the value is then increased by 1 andstored in the parent’s local-h integer. Once an imbalanceof height more than 1 is discovered, a rotation is per-formed. Higher up in the tree the balance informationmight become out of date due to concurrent structuralmodifications, but, importantly, performing these local

4

Algorithm 1 Remove and rotate operations executed by process p

1: remove(parent, left-child)p:2: if parent.rem then return false3: if left-child then n← parent.`4: else n← parent.r5: if n = ⊥ then return false6: lock(parent); lock(n);7: if ¬n.del then release-locks(); return false8: if (child← n.`) ,⊥ then9: if n.r ,⊥ then

10: release-locks(); return false11: else child← n.r12: if left-child then parent.`← child13: else parent.r← child14: n.`← parent; n.r← parent;15: n.rem← true;16: release-locks()17: update-node-heights();18: return true.

19: right-rotate(parent, left-child)p:20: if parent.rem then return false21: if left-child then n← parent.`22: else n← parent.r23: if n = ⊥ then return false24: `← n.`;25: if ` = ⊥ then return false26: lock(parent); lock(n); lock(`);27: `r← `.r; r← n.r;28: // allocate a node called new29: new.k← n.k; new.`← `r;30: new.r← r; `.r← new;31: if left-child then parent.`← `32: else parent.r← `

33: n.rem← true; // by-left-rot if left rotation34: release-locks()35: update-node-heights();36: return true.

rotations will eventually result in a balanced tree [4].Apart from performing rotations locally as unique

operations, the specific CF rotation procedure isdone differently in order to avoid using locks andaborts/rollbacks during traversals. Let us considerspecifically the typical tree right-rotation operation pro-cedure. Here we have three nodes modified during therotation: a parent node p, its child n who will be rotateddownward to the right, as well as n’s left child ` who willbe rotated upwards, thus becoming the child of p and theparent of n. Consider a concurrent traversal that is pre-empted on n during the rotation. Before the rotation, `and its left subtree exist below n as nodes in the path ofthe traversal, while afterwards (given that n is rotateddownwards) these are no longer in the traversal path,thus violating correctness if these nodes are in the correctpath. In order to avoid this, mechanisms such as handover hand locking [7] or keeping count of the numberof operations currently traversing a node [4] have beensuggested, but these solutions require traversals to makethemselves visible at each node, creating contention. In-stead, in the CF tree, the rotation operation is slightlymodified, allowing for safe, concurrent, invisible traver-sals.

The rotation procedure is then performed as followsas shown in Algorithm 1: The parent p, the node to berotated n, and n’s left child ` are locked in order to pre-vent conflicts with concurrent insert and delete opera-tions. Next, instead of modifying n like would be donein a traditional rotation, a new node new is allocated totake n’s place in the tree. The key, value, and del fieldsof new are set to be the same as n’s. The left child of newis set to `.r and the right child is set to n.r (these are thenodes that would become the children of n after a tra-

ditional rotation). Next `.r is set to point to new and p’schild pointer is updated to point to ` (effectively remov-ing n from the tree), completing the structural modifica-tions of the rotation. To finish the operation n.rem is setto true (or by-left-rot, in the case of a left-rotation) and thelocks are released. There are two important things to no-tice about this rotation procedure: First, new is the exactcopy of n and, as a result, the effect of the rotation is thesame as a traditional rotation, with new taking n’s placein the tree. Second, the child pointers of n are not modi-fied, thus all nodes that were reachable from n before therotation are still reachable from n after the rotation, thus,any current traversal preempted on n will still be able toreach any node that was reachable before the rotation.

4.4 Structural adaptation

As mentioned earlier, one of the advantages of perform-ing structural adaptation lazily is that it does not needto be executed immediately as part of the abstract op-erations. In a highly concurrent system this gives usthe possibility to use processor cores that might other-wise be idle to perform the structural adaptation, whichis exactly what is done in the CF tree. A fixed struc-tural adaption thread is then assigned the task of run-ning the background-struct-adaptation operation whichrepeatably calls the restructure-node procedure on theroot node, as shown in Algorithm 2, taking care of bal-ance and physical removal. restructure-node is simply arecursive depth-first procedure that traverses the entiretree. At each node, first the operation attempts to phys-ically remove its children if they are logically deleted.Following this, it propagates balance values from its chil-dren and if an imbalance is found, a rotation is per-

5

Algorithm 2 Restructuring operations executed by process p

1: background-struct-adaptation()p:2: while true do3: // continuous background restructuring4: restructure-node(root).

5: propagate(n)p:6: if n.` ,⊥ then n.left-h← n.`.local-h7: else n.left-h← 08: if n.r ,⊥ then n.right-h← n.r.local-h9: else n.right-h← 0

10: n.local-h←max(n.left-h,n.right-h) + 1.

11: restructure-node(node)p:12: if node = ⊥ then return13: restructure-node(node.`);14: restructure-node(node.r);15: if node.` ,⊥∧ node.`.del then16: remove(node, false)17: if node.r ,⊥∧ node.r.del then18: remove(node, true)19: propagate(node);20: if |node.left-h− node.right-h| > 1 then21: // Perform appropriate rotations.

formed.A single thread is constantly running, but having

several structural adaptations threads, or distributingthe work among application threads is also possible. Itshould be noted that, in a case where there can be multi-ple threads performing structural adaptation, we wouldneed to be more careful on when and how the locks areobtained.

4.5 Abstract operations

The abstract operations are shown in Algorithm 3. Eachof the abstract operations begin by starting their traver-sal from the root node. The traversal is then performed,without using locks, from within a while loop whereeach iteration of the loop calls the get-next procedure,which returns either the next node in the traversal, or ⊥in the case that the traversal is finished.

The get-next procedure starts by reading the rem flagof node. If the flag was set to by-left-rotate then the nodewas concurrently removed by a left-rotation. As we sawin the previous section, a node that is removed duringrotation is the node that would be rotated downwardsin a traditional rotation. Specifically, in the case of theleft rotation, the removed node’s right child is the noderotated upwards, therefore in this case, the get-next op-eration can safely travel to the right child as it containsat least as many nodes in its path that were in the pathof the node before the rotation. If the flag was set to truethen the node was either removed by a physical removalor a right-rotation, in either case the operation can safelytravel to the left child, this is because the remove opera-tion changes both of the removed node’s child pointersto point to the parent and the right-rotation is the mir-ror of the left-rotation. If the rem flag is false then thekey of node is checked, if it is found to be equal to k thenthe traversal is finished and ⊥ is returned. Otherwisethe traversal is performed as expected, traversing to theright if the node.k is bigger than k or to the left if smaller.

Given that the insert and delete operations might

modify node, they lock it for safety once ⊥ is returnedfrom get-next. Before the node is locked, a concurrentmodification to the tree might mean that the traversalis not yet finished (for example the node might havebeen physically removed before the lock was taken),thus the validate operation is called. If false is returnedby validate, then the traversal must continue, otherwisethe traversal is finished. Differently, given that it makesno modifications, the contains operation exits the whileloop immediately when ⊥ is returned from get-next.

The validate operation performs three checks on nodeto ensure that the traversal is finished. First it ensuresthat rem = false, meaning that the node has not beenphysically removed from the tree. Then it checks if thekey of the node is equal to k, in such a case the traversalis finished and true is returned immediately. If the keyis different from k then the traversal is finished only ifnode has ⊥ for the child where a node with key k wouldexist. In such a case true is returned, otherwise false isreturned.

The code after the traversal is straightforward. Forthe contains operation, true is returned if node.k = k andnode.del = false, false is returned otherwise. For theinsert operation, if node.k = k then the del flag is checked,if it is false then false is returned; otherwise if the flagis true it is set to false, and true is returned. In the casethat node.k , k, a new node is allocated with key k andis set to be the child of node. For the delete operation, ifnode.k , k, then false is returned. Otherwise, the del flagis checked, if it is true then false is returned, otherwise ifthe flag is false, it is set to true and true is returned.

5 Correctness

The contention-friendly tree is linearizable [24] in thatin any of its potentially concurrent executions, each ofits insert, delete and contains operations executes as ifit was executed at some indivisible point, called its lin-earization point, between its invocation and response. We

6

Algorithm 3 Abstract operations

1: contains(k)p:2: node← root;3: while true do4: next← get next(node,k);5: if next = ⊥ then break6: node← next;7: result← false;8: if node.k = k then9: if ¬node.del then result← true

10: return result.

11: insert(k)p:12: node← root;13: while true do14: next← get next(node,k);15: if next = ⊥ then16: lock(node);17: if validate(node,k) then break18: unlock(node);19: else node← next20: result← false;21: if node.k = k then22: if node.del then23: node.del← false; result← true24: else // allocate a node called new25: new.key← k;26: if node.k > k then node.r← new27: else node.`← new28: result← true;29: unlock(node);30: return result.

31: delete(k)p:32: node← root33: while true do34: next← get next(node,k);35: if next = ⊥ then36: lock(node);37: if validate(node,k) then break38: unlock(node);39: else node← next40: result← false;41: if node.k = k then42: if ¬node.del then43: node.del← true; result← true44: unlock(node);45: return result.

46: get-next(node,k)s:47: rem← node.rem;48: if rem = by-left-rot then next← node.r49: else if rem then next← node.`50: else if node.k > k then next← node.r51: else if node.k = k then next←⊥52: else next← node.`53: return next.

54: validate(node,k)s:55: if node.rem then return false56: else if node.k = k then return true57: else if node.k > k then next← node.r58: else next← node.`59: if next = ⊥ then return true60: return false.

proceed by showing that the execution of each operationhas a linearization point between its invocation and re-sponse, where this operation appears to execute atomi-cally.

Given that the insert and delete operations that re-turn false do not modify the tree and that all other oper-ations that modify nodes only do so while owning thenode’s locks, these failed insert and delete operationscan be linearized at any point during the time that theyown the lock of the node that was successfully validated.

The successful insert (i.e., the one that returns true)operation is linearized either at the instant it changesnode.del to false, or when it changes the child pointer ofnode to point to new. In either case, k exists in the abstrac-tion immediately after the modification. The successfuldelete operation is linearized at the instant it changesnode.del to true, resulting in k no longer being in the ab-straction.

The contains operation is a bit more difficult as itdoes not use locks. To give an intuition of how it is lin-earized, first consider a system where neither rotationsnor physical removals are performed. In this system, ifnode.k = k on line 8 is true, then the linearization pointis when node.del is read (line 9). Otherwise if node.k , k,then the linearization point is either on line 50 or 52 of

the get-next operation where ⊥ is read as the next node(meaning at the time of this read k does not exist in theabstraction).

Now, if rotations and physical removals are per-formed in the system, then a contains operation whohas finished its traversal might get preempted on a nodethat is removed from the tree. First consider the casewhere node.k = k, since neither rotations nor removalswill modify the del flag of a node, then in this case thelinearization point is simply either on line 50 or 52 of theget-next operation where the pointer to node was read.

Finally, consider the case where node.k , k. First no-tice that when false is not read from node.rem (line 47 ofget-next) then the traversal will always continue to an-other node. This is due to the facts that after a right (resp.left) rotation, the node removed from the tree will alwayshave a non-⊥ left (resp. right) child (this is the child ro-tated upwards by the rotation) and that a node removedby a remove operation will never have a ⊥ child pointer.Therefore if the traversal finishes on a node that has beenremoved from the tree, it must have read that node’s remflag before the rotation or removal had completed. Thisread will then be the linearization point of the operation.In this case, for the contains operation to complete, thenext node in the traversal must be read as ⊥ from the

7

child pointer of node, meaning that the removal/rotationhas not made any structural modifications to this pointerat the time of the read (this is because rotations make nomodifications to the child pointers of the node they re-move, and removals point the removed node’s pointerstowards its parent). Thus, given that removals and rota-tions will lock the node removed meaning no concurrentmodifications will take place, effectively the contains op-eration has observed the state of the abstraction immedi-ately before the removal took place.

6 Experimental Evaluation

We implemented the contention-friendly binary searchtree in Java and tested it on two different architecturesusing the publicly available Synchrobench benchmarksuite [17]:− A 64-way UltraSPARC T2 with 8 processors with up

to 8 hardware threads running at 1.2GHz with So-laris 10 (kernel architecture sun4v) and Java 1.7.0 05-b05 HotSpot Server VM.

− A 64-way x86-64 AMD machine with 4 sockets with16 cores each running at 1.4GHz running Fedora18 and Java 1.7.0 09-icedtea OpenJDK 64-Bit ServerVM.

− A 32-way x86-64 Intel machine with 2 sockets with8 hyperthreaded cores running at 2.1GHz runningUbuntu 12.04.5 LTS and Java 1.8.0 74 HotSpot 64-BitServer VM.

For each run, we present the maximum, minimum,and averaged numbers of operations per microsecondover 5 runs of 5 seconds executed successively as partthe same JVM for the sake of warmup. As recommendedby Synchrobench [17] we kept the range of possible val-ues twice as large as the initial size to keep the structuresize constant in expectation during the entire benchmarkrun.

6.1 Lock-based binary search trees

First, we compare the performance of the contention-friendly tree (CF-tree) against the practical lock-based bi-nary search tree (BCCO-tree [7]) on an UltraSPARC T2with 64 hardware threads, using the original code of theauthors.

Figure 1 compares the performance of the practicalBCCO tree against performance of our binary search treewith 212 (left) and 216 elements (right) and on a read-only workload (top) and workloads comprising up to20% updates (bottom). The variance of our results isquite low as illustrated by the relatively short error barswe have. While both trees scale well with the number

of threads, the BCCO tree is slower than its contention-friendly counterpart in all the various settings.

In particular, our CF tree is up to 2.2× faster thanits BCCO counterpart. As expected, the performancebenefit of our contention-friendly tree increases gener-ally with the level of contention. (We observed thisphenomenon at higher update ratios but omitted thesegraphs for the sake of space.) First, the performance im-provement increases with the level of concurrency onFigures 1(c), 1(d), 1(e) and 1(f). As each thread up-dates the memory with the same (non-null) probabilitythe contention increases with the number of concurrentthreads running. Second, the performance improvementincreases with the update ratio. This is not surprising asour tree relaxes the balance invariant during contentionpeaks whereas the BCCO tree induces more contentionto maintain the balance invariant.

6.2 Transaction-based binary search trees

We also compare the contention-friendly tree againsttwo binary search trees using Software TransactionalMemories. Note that hardware transactional memorycan only be used on small data structures and that trans-actional instructions are not available in Java, so we de-cided to use DeuceSTM [27] in its default mode to testthe performance of two transaction-based binary searchtrees.

The first transaction-based binary search tree is thered-black tree developed by Oracle and others that getrid of sentinel nodes to diminish aborts due to falseconflicts. Its code was used to implement database ta-bles in the STAMP vacation benchmark [8] that are ac-cessed through transactions and it is publicly availablein JSTAMP and as part of Synchrobench1. The sec-ond is the speculation-friendly binary search tree algo-rithm [10] especially tuned to reduce the size of transac-tions by decoupling rotations from the insertion and re-moval of nodes. We ported the existing implementationfrom C that is publicly available online2 to Java and usedthe DeuceSTM bytecode instrumentation framework aswell.

Figure 2 depicts the performance of the transaction-based binary search tree with 10% updates on both ourAMD platform (x86-64) and our Niagara 2 (SPARC)platform. To have a clearer view of the shape of thetransaction-based BST curves, we used a logarithmicscale on the y-axis. The difference in performance be-tween the transaction-based binary search trees and ourcontention-friendly binary search tree is substantial. Thereason is mainly explained by the overhead induced by

1https://sites.google.com/site/synchrobench2https://github.com/gramoli/synchrobench/tree/master/

src/sftree.

8

0  

5  

10  

15  

20  

25  

30  

0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

(a) 212 elements, 0% update

0  

5  

10  

15  

20  

25  

0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

(b) 216 elements, 0% update

0  

5  

10  

15  

20  

25  

30  

0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

(c) 212 elements, 10% update

0  

5  

10  

15  

20  

0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

(d) 216 elements, 10% update

0  

5  

10  

15  

20  

25  

0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

(e) 212 elements, 20% update

0  

5  

10  

15  

20  

0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

(f) 216 elements, 20% update

Figure 1: Performance of our contention-friendly tree and the practical concurrent tree [7]

DeuceSTM that instruments the bytecode to produce atransactional version that uses metadata, like read-setand write-set to check the consistency of executions. In-terestingly, the curves of the transaction-based binarysearch trees is smoother on the SPARC architecture,probably due to operating system and architectural op-timisations for the JVM.

6.3 Lock-free binary search trees

Finally, we compare the contention-friendly tree againsttrees providing lock-free operations. Similar to ourtree, the logical ordering binary search thee (DVY) [11]provides lock-free contains operations and separate thephysical structure from the abstract representation. Asopposed to our tree though, it does not have transientstates where nodes are logically deleted without beingphysically removed from the tree. The non-blockingbinary search tree (EFRB) [14] uses exclusively single-word compare-and-swap for synchronization. Its con-

tains operation never updates the structure and the treeis not balanced. The code of both algorithms is availableonline.

Figure 3 depicts the results obtained with the existinglock-free binary search tree (EFRB) and the logical order-ing binary search tree (DVY). We can see that the DVY-tree is slower than the contention-friendly binary searchtree at all thread counts on both architectures. Whilethe DVY-tree uses a similar decoupling technique, it im-mediately physically remove node from the structurehence affecting the structure each time a remove occur.By contrast, the contention-friendly tree does not im-mediately remove a node from the structure but simplymarks it as logically deleted, hence minimising the con-tention even with only 10% updates. Finally the EFRBtree presents performance on SPARC that are similar tothe contention-friendly tree as it only uses single-wordcompare-and-swap to synchronise threads and becausethe workload is uniformly distributed. Even though the

9

0.1  

1  

10  

100  

0   4   8   12  16  20  24  28  32  36  40  44  48  52  56  60  64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

CF-­‐Tree   Tx-­‐RBTree   SF-­‐Tree  

(a) AMD platform

0.01  

0.1  

1  

10  

100  

0   4   8   12  16  20  24  28  32  36  40  44  48  52  56  60  64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

CF-­‐Tree   Tx-­‐RBTree   SF-­‐tree  

(b) SPARC platform

Figure 2: Transaction-based binary search trees vs. thecontention-friendly tree (214 elements and 10% updates)

0  10  20  30  40  50  60  

0   4   8   12  16  20  24  28  32  36  40  44  48  52  56  60  64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

CF-­‐Tree   DVY-­‐Tree   EFRB-­‐Tree  

(a) AMD platform

0  

5  

10  

15  

20  

25  

0   4   8   12  16  20  24  28  32  36  40  44  48  52  56  60  64  

Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

CF-­‐Tree   DVY-­‐Tree   EFRB-­‐Tree  

(b) SPARC platform

Figure 3: Lock-free binary search trees vs. thecontention-friendly tree (214 elements and 10% updates)

0  

10  

20  

30  

40  

50  

0   4   8   12   16   20   24   28   32  Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

CF-­‐Tree   BCCO-­‐Tree   EFRB-­‐Tree   DVY-­‐Tree  

(a) Intel platform - 212 elements - 100% update

0  

10  

20  

30  

40  

0   4   8   12   16   20   24   28   32  Throughp

ut  (o

ps/m

icrosec)  

Number  of  threads  

CF-­‐Tree   BCCO-­‐Tree   EFRB-­‐Tree   DVY-­‐Tree  

(b) Intel platform - 214 elements - 100% update

Figure 4: The lock-free and lock-based trees under heavycontention

workload is also uniformly distributed on x86-64, wecan see that the contention-friendly tree remains fasterthan the EFRB tree. This result is particularly remark-able given that the workload is balanced which shouldnot penalise the performance of the EFRB tree that can-not rotate.

6.4 Performance under high contention

To further stress test the contention-friendly tree, wecompared the performance of the lock-free and lock-based trees on smaller data structures with a higher up-date ratio. The results are depicted in Figure 4. Notethat the update are attempted as Synchrobench cannotrun 100% updates without becoming deterministic. Wecan clearly observe that the performance of the EFRBand the DVY trees is more impacted by the contentionthan the performance of the contention-friendly tree, asthe performance gain of the contention-friendly tree iseven higher than on Figure 3. The BCCO performanceis slightly better than the DVY tree but remains signifi-cantly lower than the contention-friendly tree. In partic-ular the performance of the BCCO tree is twice slowerthan the contention-friendly at 32 threads.

7 Conclusion

The contention-friendly methodology is promising forincreasing performance of data structure on multicore

10

architectures where the number of cores potentially up-dating the structure continues to grow. It achieves thisgoal by decoupling the abstraction modifications fromthe structural modifications, hence limiting the inducedcontention. We illustrated our methodology with a lock-based binary search tree that we implemented in Java.The comparison of its performance against five state-of-the-art tree structures and on two different multicore ar-chitectures indicates that our tree is efficient even underreasonable contention.

Availability

The source code of all the data structures tested inthis paper were made publicly available online athttps://github.com/gramoli/synchrobench/tree/

master/java/src/trees/ with the BCCO-Tree locatedat lockbased/LockBasedStanfordTree.java, the EFRB-Tree at lockfree/NonBlockingTorontoBSTMap.java,the DVY-Tree at lockbased/LogicalOrderingAVL.java,the CF-Tree atlockbased/LockBasedFriendlyTreeMap.java, the SF-Tree attransactional/TransactionalFriendlyTreeSet.java

and the Tx-RBTree attransactional/TransactionalRBTreeSet.java.

Acknowledgments

This research was supported under Australian ResearchCouncil’s Discovery Projects funding scheme (projectnumber 160104801) entitled “Data Structures for Multi-Core”. Vincent Gramoli is the recipient of the AustralianResearch Council Discovery International Award.

References

[1] G. Adelson-Velskii and E. M. Landis. An algorithmfor the organization of information. In Proc. of theUSSR Academy of Sciences, volume 146, pages 263–266, 1962.

[2] R. Bayer. Symmetric binary B-trees: Data struc-ture and maintenance algorithms. Acta Informatica1, 1(4):290–306, 1972.

[3] R. Bayer and E. McCreight. Organization and main-tenance of large ordered indices. In Proc. of theACM Workshop on Data Description, Access and Con-trol, pages 107–141, 1970.

[4] L. Bouge, J. Gabarro, X. Messeguer, and N. Sch-abanel. Height-relaxed AVL rebalancing: A uni-fied, fine-grained approach to concurrent dictionar-ies. Technical Report RR1998-18, ENS Lyon, 1998.

[5] J. Boyar, R. Fagerberg, and K. S. Larsen. Amortiza-tion results for chromatic search trees, with an ap-plication to priority queues. J. Comput. Syst. Sci.,55(3):504–521, 1997.

[6] A. Braginsky and E. Petrank. A lock-free b+tree. InSPAA, pages 58–67, 2012.

[7] N. G. Bronson, J. Casper, H. Chafi, and K. Olukotun.A practical concurrent binary search tree. In PPoPP,2010.

[8] C. Cao Minh, J. Chung, C. Kozyrakis, and K. Oluko-tun. STAMP: Stanford transactional applications formulti-processing. In IISWC, 2008.

[9] T. Crain, V. Gramoli, and M. Raynal. Brief an-nouncement: A contention-friendly, non-blockingskip list. In DISC, pages 423–424, 2012.

[10] T. Crain, V. Gramoli, and M. Raynal. A speculation-friendly binary search tree. In PPoPP, pages 161–170, 2012.

[11] T. Crain, V. Gramoli, and M. Raynal. A contention-friendly binary search tree. In Euro-Par, volume8097 of LNCS, pages 229–240, 2013.

[12] T. Crain, V. Gramoli, and M. Raynal. No hot spotnon-blocking skip list. In ICDCS, 2013.

[13] I. Dick, A. Fekete, and V. Gramoli. Logarithmicdata structures for multicores. Technical Report 697,University of Sydney, 2014.

[14] F. Ellen, P. Fatourou, E. Ruppert, and F. van Breugel.Non-blocking binary search trees. In PODC, pages131–140, 2010.

[15] P. Felber, V. Gramoli, and R. Guerraoui. Elastictransactions. In DISC, pages 93–108, 2009.

[16] K. Fraser. Practical lock freedom. PhD thesis, Cam-bridge University, September 2003.

[17] V. Gramoli. More than you ever wanted to knowabout synchronization: Synchrobench, measuringthe impact of the synchronization on concurrent al-gorithms. In PPoPP, pages 1–10, 2015.

[18] V. Gramoli, P. Kuznetsov, S. Ravi, and D. Shang. Aconcurrency-optimal list-based set. Technical Re-port 1502.01633, arXiv, Feb. 2015.

[19] L. J. Guibas and R. Sedgewick. A dichromaticframework for balanced trees. In FOCS, pages 8–21, 1978.

[20] T. Harris. A pragmatic implementation of non-blocking linked-lists. In DISC, pages 300–314, 2001.

11

[21] S. Heller, M. Herlihy, V. Luchangco, M. Moir,W. N. S. III, and N. Shavit. A lazy concurrentlist-based set algorithm. Parallel Processing Letters,17(4):411–424, 2007.

[22] M. Herlihy, Y. Lev, V. Luchangco, and N. Shavit. Asimple optimistic skiplist algorithm. In SIROCCO,pages 124–138, 2007.

[23] M. Herlihy and N. Shavit. The Art of MultiprocessorProgramming. Morgan Kauffman, 2008.

[24] M. P. Herlihy and J. M. Wing. Linearizability: acorrectness condition for concurrent objects. ACMTrans. Program. Lang. Syst., 12:463–492, July 1990.

[25] S. Huddleston and K. Mehlhorn. A new data struc-ture for representing sorted lists. Acta Inf., 17:157–184, 1982.

[26] J. L. W. Kessels. On-the-fly optimization of datastructures. Commun. ACM, 26(11):895–901, 1983.

[27] G. Korland, N. Shavit, and P. Felber. Deuce: Nonin-vasive software transactional memory. Transactionson HiPEAC, 5(2), 2010.

[28] Y. Mao, E. Kohler, and R. T. Morris. Cache crafti-ness for fast multicore key-value storage. In Eu-roSys, pages 183–196, 2012.

[29] M. M. Michael. High performance dynamic lock-free hash tables and list-based sets. In SPAA, pages73–82, 2002.

[30] C. Mohan. Commit-LSN: a novel and simplemethod for reducing locking and latching in trans-action processing systems. In VLDB, pages 406–418,1990.

[31] A. Natarajan and N. Mittal. Fast concurrent lock-free binary search trees. In PPoPP, pages 317–328,2014.

[32] O. Nurmi and E. Soisalon-Soininen. Uncou-pling updating and rebalancing in chromatic binarysearch trees. In PODS, pages 192–198, 1991.

[33] O. Nurmi and E. Soisalon-Soininen. Chromatic bi-nary search trees. A structure for concurrent rebal-ancing. Acta Inf., 33(6):547–557, 1996.

[34] M. Raynal. Concurrent Programming: Algorithms,Principles, and Foundations. Springer, 2013.

12