The Amortized Analysis of a Non-blocking Chromatic Tree

A non-blocking chromatic tree is a type of balanced binary search tree where multiple processes can concurrently perform search and update operations. We prove that a certain implementation has amortized cost $O(\dot{c} + \log n)$ for each operation, where $\dot{c}$ is the maximum number of concurrent operations during the execution and $n$ is the maximum number of keys in the tree during the operation. This amortized analysis presents new challenges compared to existing analyses of other non-blocking data structures.


Introduction
A concurrent data structure is one that can be concurrently updated by multiple processes. A wait-free implementation of a concurrent data structure guarantees that every operation completes within a finite number of steps by the process that invoked the operation. A non-blocking implementation of a concurrent data structure guarantees that whenever there are active operations, one operation will eventually complete in a finite number of steps. Since a particular operation may not complete in a finite number of steps, it not possible to perform a worst-case analysis for non-blocking data structures. However, such implementations are desirable since they are typically less complicated than wait-free implementations and often perform well in practice. Amortized analysis gives an upper bound on the worst-case number of steps performed during a sequence of operations in an execution, rather than on the worst-case step complexity of a single operation. This type of analysis is useful for expressing the efficiency of non-blocking data structures.
In this paper, we present an amortized analysis of a non-blocking chromatic tree. The chromatic tree was introduced by Nurmi and Soisalon-Soininen [11] as a generalization of a red-black tree with relaxed balance conditions, allowing insertions and deletions to be performed independently of rebalancing. Boyar, Fagerberg, and Larsen [1] showed that the amortized number of rebalancing transformations per update is constant, provided each update and each rebalancing transformation is performed without interference from other operations. Brown,Ellen,and Ruppert [4] gave a non-blocking implementation using LLX and SCX primitives [3], which themselves can be implemented using CAS. Unfortunately, this implementation does not have good amortized complexity. We prove that a slightly modified implementation has amortized cost O(ċ(α) + log n(op)) for each operation op in an execution α, whereċ(α) is the point contention of α and n(op) is the maximum number of nodes in the chromatic tree during op's execution interval.
Our amortized analysis for the chromatic tree is based on the amortized analysis for the unbalanced binary search tree by Ellen,Fatourou,Helga,and Ruppert [6]. Several challenges make our analysis more difficult than their analysis.
The unbalanced binary search tree only has one transformation to perform insertions and one transformation to perform deletions. The chromatic tree also has 11 different rebalancing transformations (not including their mirror images). Our analysis has the feature that it does not require a separate case for each type of transformation performed. A very similar analysis should give the same amortized step complexity for other types of balanced binary search trees, especially for those implemented using LLX and SCX [2].
Unlike update transformations, which only occur at leaf nodes, rebalancing transformations may occur anywhere in the tree. Furthermore, operations may perform rebalancing transformations on behalf of other operations, or may cause them to perform additional rebalancing transformations they would otherwise not perform. For an amortized analysis done using the accounting method, these facts make it much more difficult to determine the steps in which dollars should be deposited into bank accounts to pay for future steps.
Much like the analysis of the unbalanced binary search tree, many overlapping transformations can cause all but one to fail. Many operations may also be working together to perform the same rebalancing transformations. The amortized analysis of the chromatic tree is complicated by the fact that the constant upper bound on the number of rebalancing transformations per operation is amortized, even when each update and rebalancing transformation is performed atomically. Since the number of rebalancing transformations performed by each operation may differ, a bad configuration in which many rebalancing transformations can occur may also have high contention. Executions including such configurations must be accounted for in the amortized analysis.
The remainder of this paper is organized as follows. In Section 2, we present the asynchronous shared memory model assumed in our analysis. In Section 3, we give an overview of related work done on the amortized analysis of concurrent data structures. In Section 4, we give an overview of chromatic trees, the LLX and SCX primitives, and the implementation of the chromatic tree by Brown, Ellen, and Ruppert. In Section 5, we make optimizations to the chromatic tree implementation to improve its amortized step complexity. Finally, in Section 6, we prove the amortized step complexity of the modified chromatic tree.

Model
Throughout this paper, we use an asynchronous shared memory model. Shared memory consists of a collection of shared variables accessible by all processes in a system. Processes access or modify shared variables using primitive instructions that are performed atomically: Write(r, value), which stores value into the shared variable r, Read(r), which returns the value stored in r, and compare-and-swap (CAS). CAS(r, old, new) compares the value stored in shared variable r with the value old. If the two values are the same, the value stored in r is replaced with the value new and True is returned; otherwise False is returned.
A configuration of a system consists of the values of all shared variables and the states of all processes. A step by a process either accesses or modifies a shared variable, and can also change the state of the process. An execution is an alternating sequence of configurations and steps, starting with a configuration. A solo execution from a configuration C by a process P is an execution starting from C in which all steps are performed by P .
An abstract data type is a collection of objects and operations that satisfies certain properties. A concurrent data structure for the abstract data type provides representations of the objects in shared memory and algorithms for the processes to perform the operations. An operation on a data structure by a process becomes active when the process performs the first step of its algorithm. The operation becomes inactive after the last step of the algorithm is performed by the process. The execution interval of the operation consists of all configurations in which it is active. In the initial configuration, the data structure is empty and there are no active operations.
An execution α is linearizable if one can assign linearization points to each completed operation and a subset of the uncompleted operations in α with the following properties. First, the linearization point of an operation is within its execution interval. Second, the return value of each operation in α must be the same as in the execution in which the same operations are performed atomically in order of their linearization points. A concurrent data structure is considered to be correct if all executions of its operations are linearizable.
A non-blocking implementation of a concurrent data structure guarantees that whenever there are active operations, one operation will eventually complete in a finite number of steps. However, the execution interval of any particular operation in an execution may be unbounded, provided other operations are completed. A wait-free implementation of a concurrent data structure guarantees that every operation completes within a finite number of steps by the process that invoked the operation.
The step complexity of an operation op invoked by process P is the number of steps performed by P in the execution interval of op. The worst-case step complexity of an operation is the maximum number of steps taken by a process to perform any instance of this operation in any execution. The amortized step complexity of a data structure is the maximum number of steps in any execution consisting of operations on the data structure, divided by the number operations invoked in the execution. One can determine an upper bound on the amortized step complexity by assigning an amortized cost to each operation, such that for all possible executions α on the data structure, the total number of steps taken in α is at most the sum of the amortized costs of the operations in α. The amortized cost of a concurrent operation is often expressed as a function of contention. For a configuration C, we define its contentionċ(C) to be the number of active operations in C. For an operation op in an execution α, we define its point contentionċ(op) to be the maximum number of active operations in a single configuration during the execution interval of op. Finally, for an execution α, we define its point contentionċ(α) to be the maximum number of active operations in a single configuration during α. 1: LLX(r) by process P 2: ⊲ Precondition: r = Nil ⊲ order of lines 3-6 matters 3: marked 1 := r.marked 4: rinfo := r.info 5: state := rinfo.state 6: marked 2 := r.marked 7: if state = Aborted or (state = Committed and not marked 2 ) then ⊲ if r was not frozen at line 5 8: read r.m 1 , . . . , r.m y and record values in local variables m 1 , . . . , m y 9: if r.info = rinfo then ⊲ if r.info unchanged since line 4 10: Store r, rinfo, m 1 , . . . , m y in P 's local table 11: return m 1 , . . . , m y 12: if (rinfo.state = Committed or (rinfo.state = InProgress and Help(rinfo))) and marked 1 then ⊲ Preconditions: (1) for each r in V , P has performed an invocation I r of LLX(r) linked to this SCX (2) new is not the initial value of f ld (3) for each r in V , no SCX(V ′ , R ′ , f ld, new) was linearized before I r was linearized 19: Let infoFields be a pointer to a newly created table in shared memory containing for each r in V , a copy of r's info value in P 's local ⊲ Freeze all Data-records in scxP tr.V to protect their mutable fields from being charged by other SCXs

24:
for each r in scxP tr.V enumerated in order do

25:
Let rinfo be the pointer indexed by r in scxP tr.infoFields 26: if not CAS(r .info, rinfo, scxPtr ) then ⊲ Freezing CAS return True Figure 2: Pseudocode for LLX and SCX given in [3]. marked bit is used to finalize nodes. A node is only removed from the chromatic tree after it is marked. Once a marked bit is set to True, it cannot be changed back to False. An SCX-record contains fields of information required for processes to finish an SCX on another process's behalf. It also contains a state field whose value is either InProgress, Aborted, or Committed, and is initially InProgress. Consider an SCX(V, R, f ld, new) performed by a process P . P first creates a new SCX-record U for this SCX. A Data-record r is frozen for U if r.info points to U and either U.state = InProgress, or U.state = Committed and r is marked. Freezing acts like a lock on a Data-record held by a particular operation. For each Data-record v ∈ V , P attempts to freeze v by setting v.info to point to U using a freezing CAS. This only succeeds if v has not been frozen since P 's last LLX on v. If the freezing CAS fails and no other process has frozen v for U , then P performs an abort step and returns False. An abort step atomically unfreezes all Data-records frozen for U by setting U to the Aborted state.
Once all Data-records in V are successfully frozen for U , the SCX can no longer fail. Then each Data-record in R ⊆ V is marked for removal and an update CAS sets f ld to the value new. Finally, a commit step is performed, which atomically unfreezes all nodes in V − R by setting U to the Committed state. The Data-records in R remain frozen.
Consider an LLX(r) by a process P . If r is marked when the LLX is invoked, P will help the SCX that marked r (if it is not yet complete) and return Finalized. Otherwise P attempts to take a snapshot of the fields of r. If r is not frozen while P reads each of its fields, the LLX is successful and returns the fields of r. If a concurrent SCX operation freezes r sometime during P 's LLX, P may help the concurrent SCX complete before returning Fail.
LLX and SCX guarantee non-blocking progress. If SCX is performed infinitely often, then an infinite number succeed. Much of our amortized analysis will require a mechanism to charge failed LLX and SCX of one operation to the other operation that caused it to fail.

An Implementation of a Chromatic Tree using LLX and SCX
We next give an overview of the non-blocking implementation of a chromatic tree using LLX and SCX primitives by Brown,Ellen,and Ruppert [4]. The nodes of the chromatic tree are represented as Data-records with fields as shown in Figure 3. ⊲ Fields used for the chromatic tree 3: left , right ⊲ (Mutable) Node pointers to left and right children 4: k, w ⊲ (Immutable) key and weight 5: ⊲ Fields used by LLX/SCX algorithm 6: info ⊲ pointer to an SCX-record 7: marked ⊲ Boolean flag to mark node to be Finalized The implementation uses additional sentinel nodes with keys ∞ and weight 1. (See Figure 4.) The sentinel nodes help prevent edge cases when the root of a chromatic tree is involved in transformations. The key ∞ is greater than all keys in the chromatic tree, and is not the key of any element in the dynamic set. We do not consider a sentinel node which is a leaf to be in violation of balance condition (C2) from Definition 4.2. An empty chromatic tree is represented by one internal node entry with two children, all with keys ∞. A non-empty chromatic tree has two internal sentinel nodes at the parent and grandparent of the chromatic tree, each of which also has a sentinel node as its right child. A node x is in the chromatic tree in a configuration C if x is reachable from entry in C. We give an overview of the algorithm to Insert an element with key k into a chromatic tree. The Insert operation is divided into an update phase and a cleanup phase. An update phase repeatedly performs update attempts until one is successful. An update attempt begins by invoking Search(k). It searches for key k starting at entry, until it reaches some leaf l. Let p denote the node visited immediately before reaching l. If l.key = k, then the key is already in the chromatic tree, and so Insert returns False. Otherwise TryInsert(p, l) is invoked, which attempts to perform an LLX on the nodes p and l, followed by a single SCX to apply the Insert transformation (as shown in Figure 5). The invocation of TryInsert fails if any LLX or SCX fails, in which case a new update attempt begins. Once a successful TryInsert is performed, the operation enters its cleanup phase if a violation was created; otherwise the Insert terminates.
During the cleanup phase, a search for k is again performed starting at entry. If a violation is encountered at a node v during this search, TryRebalance (ggp, gp, p, v) attempts to remove the violation, where p, gp, and ggp are the last 3 nodes visited on the search to v. Whether or not TryRebalance succeeds, the cleanup restarts its search at entry. The cleanup phase terminates when the search from entry reaches a leaf without encountering a violation.
In any configuration, the search path for a key k from a node r is the path that is followed when searching for k starting at r. If r = entry, this is called the search path for k. The rebalancing transformations designed by Brown,Ellen,and Ruppert [4] have the following key property. Lemma 4.5. If a violation is on the search path for key k before a rebalancing transformation, then the violation is still on the search path for k after the rebalancing transformation, or it has been removed.
This guarantees that when a process reaches a leaf node in its cleanup phase, the violation created during its update phase has been removed.
The algorithm to Delete an element is similar to the algorithm for Insert, except with TryInsert(p, l) replaced with TryDelete(gp, p, l). TryDelete(gp, p, l) performs LLX on the nodes gp, p, l, and the sibling of l before performing an SCX to complete the Delete transformation (as shown in Figure 5). Likewise, the routine TryRebalance determines a suitable rebalancing transformation to perform by a series of LLXs, followed by a single SCX. TryRebalance has an extra failure condition called a Nil check, which is used to guarantee Nil pointers are not traversed. These checks may fail when a nearby node is modified by a concurrent operation.
Each chromatic tree transformation is outlined in Figure 5. Each transformation has a symmetric version with left and right interchanged. The rebalancing transformations preserve the weighted level of all leaves. Notice that all transformations can be performed by using SCX(V, R, f ld, n) to update a single child pointer of the node labeled u to point to the new node n. We use the notation u x to denote any child of the node u, u l to denote the left child of u, and u r to denote the right child of u. Any weight restrictions are to the right of each node. Each node in the set V of this SCX is shaded in gray. Nodes marked with × are the nodes in the set R and are finalized, while the nodes marked with + are newly created nodes. Each transformation is marked with a center node, which is highlighted with a bold outline. The only exception is BLK, whose center node for BLK is the first node in the sequence (u xll , u xlr , u xrl , u xrr ) with weight 0. A rebalancing transformation is centered at a violation if the violation occurs at the center node of the transformation. The center node will be used to identify an update operation that can be charged for performing each transformation.
A transformation may create, remove, or move violations. The first two columns of Figure 6 describe how violations are created or removed in each transformation. Any violation in R that is not removed is moved to one of the newly added nodes, as described in the third column. Note that for RB1 and BLK, the red-red violation at the center node is removed by changing its parent to a node with weight 1. Also note that for W7, an overweight from u xr is moved to n if u x .w > 0 (rather than saying 1 violation is created at n, and 1 is removed from each of u xl and u xr ).
All rebalancing transformations remove 1 violation at the center node, except for BLK and PUSH. When BLK and PUSH do not remove a violation at the center node, they instead elevate the violation, moving it to a new node higher in the tree. In particular, if u x .w = 1 and u.w = 0, then a BLK transformation centered at u xxx elevates the red-red violation at u xxx to the node n. If u x .w > 0, then a PUSH transformation elevates 1 overweight violation at u xl to the node n.
For every violation v, let the creator of v be the process that invoked the SCX that created v during a TryInsert or TryDelete. Whenever a violation v is moved or elevated to a new node, the creator of the violation does not change.
Inspection of the rules outlined in Figure 6 gives the following facts: 1. Only Insert and Delete transformations that create a violation can increase the total number of violations in the chromatic tree.

2.
A rebalancing transformation that elevates a violation does not increase the total number of violations in the chromatic tree.
3. A rebalancing transformation that does not elevate a violation decreases the total number of violations in the chromatic tree.
4. The violation at the center node of a rebalancing transformation is either removed or elevated.
When the SCX is performed, nodes are frozen top-down, starting with the nodes on the path from u to the center node. For an SCX(V, R, f ld, new), we classify each node in V as either a downwards node or a cross node, which depends on the order that the nodes are frozen. Definition 4.6. Consider an invocation S of SCX(V, R, f ld, new), where V = {v 1 , . . . , v k }, enumerated in the order they are frozen. For 1 ≤ i < k, v i is a cross node for S if v i is the sibling of v i+1 , otherwise v i is a downwards node for S. We define v k to be a downwards node for S.
Only the Delete, W1-W7, PUSH, and BLK transformations contain cross nodes. If BLK is centered at either u xrl or u xrr , then u xr is the only cross node. In the rest of these transformations, u xl is the only cross node. All other gray nodes in Figure 5 are downwards nodes.

Chromatic Tree Modifications
The chromatic tree implementation as described by Brown,Ellen,and Ruppert [4] has poor amortized step complexity. For example, consider the following execution, which begins with N processes invoking Insert(k), where k is the key of an element to be inserted at a node with depth h. The following three sequences of steps are repeated: 1. All N processes traverse the tree from entry to the insertion point of k and successfully perform all required LLXs.
2. One process P performs a successful SCX and completes its Insert(k). Each other process fails its SCX and begins a new attempt of Insert(k).
Each time we repeat steps 1-3, a single Insert and a single Delete are completed by process P . However, the N processes traverse the tree from entry to the insertion point of k a total of N + 1 times. Even if we assume no rebalancing is necessary, Ω(h · N ) steps are taken for each completed operation in the execution. This results from processes restarting their search from entry each time an insertion attempt fails. In this section, we show how the implementation can be modified so that it has O(h + N ) amortized step complexity.

Violations Removed Violations Moved Insert
• red-red at n (if u x .w = 1 and u.w = 0) • None • 1 overweight at u xl • from u x to n • red-red at u xrlll , u xrllr , or u xrr (if any) • u xl .w − 2 overweight from u xl to n lll W4 • None • 1 overweight at u xl • from u x to n • red-red at u xrlrl or u xrlrr (if any) • u xl .w − 2 overweight from u xl to n ll W5 • None • 1 overweight at u xl • from u x to n • red-red at u xrrl or u xrrr (if any) • u xl .w − 2 overweight from u xl to n ll W6 • None • 1 overweight at u xl • from u x to n • red-red at u xrll or u xrlr (if any) • u xl .w − 2 overweight from u xl to n ll W7 • None • u xr .w − 2 overweight from u xr to n r , and 1 overweight from • u xl .w − 2 overweight from u xl to n l Figure 6: Violations created, removed, or moved after each transformation.

Modifying the Search Routine
Instead of restarting the search routine from entry after a failed update attempt, we backtrack through the path of visited nodes until an unmarked node is reached. Each process maintains a local stack of nodes visited along its search path. As discussed in Section 3, this technique was used previously to give good amortized step complexity for the update operations of a binary search tree [6].
if stack is empty then l := entry while l is not a leaf do ⊲ Search for leaf containing k 8: Push(stack, l) 9: if k < l.key then l := l.left else l := l.right 10: p := Pop(stack) 11: gp := Top(stack) ⊲ Necessary for Delete only 12: return gp, p, l In the first attempt of an update operation, an empty stack is initialized for BacktrackingSearch. Invocations of BacktrackingSearch in subsequent attempts use the same stack. A process is backtracking between the time when a node is popped from the stack on line 3 and when an unmarked node is found on line 4. Otherwise the process is looking for a leaf . The stack allows searches to restart at the first unmarked node encountered in the stack after a failed attempt, rather than from entry. The following facts about using a stack for backtracking in a binary search tree were shown in [6].
1. The first node that is pushed onto the stack is entry.
2. The node entry is never popped from the stack.
3. Only nodes that are or have been in the chromatic tree are pushed onto a process's stack.
4. If a node x appears immediately below node y in a process's stack, then x was the parent of y in some previous configuration.

Proof of Correctness
We argue that the first unmarked node x visited by a process P during backtracking after a failed TryInsert(k) or TryDelete(k) is on the search path for key k starting from entry. This implies that a solo run of Search(k) will pass through x, and so x is a valid restarting point for BacktrackingSearch(k, stack). We first show that unmarked nodes are in the chromatic tree after they are added by some SCX.
Lemma 5.2. Any unmarked node in configuration C that has been previously added to the chromatic tree is in the chromatic tree in C.
Proof. Consider any node unmarked node x in C that has been added to the chromatic tree in some configuration before C. Recall that nodes must be marked before they can be removed from the chromatic tree, and that marked nodes cannot be unmarked. Since x is unmarked in C, it could not have been removed from the chromatic tree since the configuration in which it was added. Therefore, x is in the chromatic tree.
Since updates are performed in the same way as in the original chromatic tree implementation, the following fact proven in [4] still holds. Lemma 5.3. If a node x is in the data structure in some configuration C and x was on the search path for key k in some earlier configuration, then x is on the search path for k in C.
A process in its update phase visits a node x if its local variable l in an instance of BacktrackingSearch points to x. We use the previous result to show that any nodes visited during BacktrackingSearch(k, stack) when looking for a leaf were on the search path for k in some earlier configuration. Lemma 5.4. Consider an instance I of BacktrackingSearch(k, stack), and let C be a configuration during I sometime after backtracking. Let C ′ be the configuration immediately after the last node popped during the backtracking of I, or the configuration after I is invoked if no such pop occurred. If x is the node pointed to by I's local variable l in C, then there is a configuration between C ′ and C in which x is on the search path for k.
Proof. We prove by induction on the configurations of an execution. We assume the lemma is true for all configurations before C, and show it is true in C.
Suppose I has not yet executed line 9 since the end of backtracking. If l points to entry, then the lemma holds because entry is always in the chromatic tree and is on the search path for every key. So suppose l points to the last node popped from the stack during backtracking in C. By the check on line 4, x is unmarked in C ′ (since the check on line 4 occurs after x is popped and marked nodes do not become unmarked). By Observation 5.1.3, x was in the chromatic tree in some configuration before it was pushed onto the stack. Therefore, by Lemma 5.2, x is in the chromatic tree in C. By the induction hypothesis, x was on the search path for k during some earlier invocation of BacktrackingSearch(k, stack) that pushed x onto the stack. Since x is in the chromatic tree in C and on the search path for k in a configuration before C, by Lemma 5.3, x is on the search path for k in C.
So suppose I has executed line 9 at least once since the end of backtracking. Since l is only updated on line 9 after backtracking, we show the lemma holds in the configuration C immediately after l is updated on this line. Let y be the node pointed to by l in the configuration C − immediately before C. By the induction hypothesis, there is a configuration C ′′ between C ′ and C − such that y is on the search path for k in C ′′ . From the code, line 9 updates l to the next node on the search path for k. So if x is a child of y in C ′′ , then x is on the search path for k in C ′′ . Since C ′′ is between C ′ and C, the lemma holds. If x is not a child of y in C ′′ , then there is a successful SCX that changes a child pointer of y to point to x in some configuration between C ′′ and C. Let C ′′′ be the configuration immediately after this SCX. The node whose pointer is updated by an SCX is in the chromatic tree before and after the SCX, so y is in the chromatic tree in C ′′′ . By Lemma 5.3, y is on the search path for k in C ′′′ . Since x is the child of y in C ′′′ , x is on the search path for k in C ′′′ . Since C ′′′ is between C ′ and C, the lemma holds.
It was shown that each successful Insert and Delete operation implemented using Search can be linearized at its successful SCX in TryInsert and TryDelete, respectively [4]. This is used to show Insert and Delete operations using BacktrackingSearch can also be linearized at the same places. Lemma 5.5. Consider an invocation S of BacktrackingSearch(k, stack) that terminates in configuration C. Let the sequence of nodes returned by S be gp, p, l . Suppose an atomic invocation S ′ of Search(k) is performed in a configuration C ′ after C. If the nodes gp, p and l are in the chromatic tree in C ′ , then S ′ returns gp, p, l .
Proof. To prove S ′ returns gp, p, l , we show the nodes gp, p, and l must be last three nodes on the search path for k from entry in C ′ .
We first argue l is a leaf and on the search path for k in C ′ . By the check on line 16, S only returns after visiting a leaf, so l is a leaf in C. There are no chromatic tree transformations that update the child pointers of leaves, so l is a leaf in C ′ . By Lemma 5.4, there exists a configuration before C in which l was on the search path for k. Since l is in the chromatic tree in C ′ , by Lemma 5.3, l is on the search path for k in configuration C ′ .
Next, we argue p is the parent of l and gp is the grandparent of l in C ′ . Let C l be the configuration immediately after S visits l. By assumption, S returns gp, p, l , so the top two nodes on stack in C l must be gp and p. Therefore, by Observation 5.1.4, there exists a configuration in which gp is the parent of p, and a configuration in which p is the parent of l. Inspection of the chromatic tree transformations shows that whenever a pointer of a node is modified, the node referenced by the pointer is removed from the chromatic tree. Therefore, no node can be inserted between p and l without removing l from the chromatic tree. So p is the parent of l in C ′ . Similarly, gp is the parent of p in C ′ .
Therefore, the nodes gp, p, and l are the last three nodes on the search path for k from entry in C ′ . This proves S ′ will return the nodes gp, p, l . Theorem 5.6. An Insert or Delete operation implemented using BacktrackingSearch can be linearized at its successful SCX in TryInsert or TryDelete, respectively.
Proof. Consider a successful invocation of TryDelete(gp, p, l). Let C ′ be the configuration immediately before its invocation of SCX. This SCX guarantees the nodes gp, p, and l are in the chromatic tree in C ′ . Consider the last invocation of BacktrackingSearch before C ′ . It returned gp, p, l . By Lemma 5.5, this invocation of BacktrackingSearch can be replaced with an atomic invocation of Search in C ′ that also returns gp, p, l . Since a Delete operation using Search can be linearized at its successful SCX in TryDelete, this implies a Delete operation using BacktrackingSearch can also be linearized at its successful SCX in TryDelete. A similar argument can be made for Insert.

Modifying the Cleanup Phase
In the original cleanup phase, operations also restart searches from entry after rebalancing attempts, regardless of whether the rebalancing succeeds or fails. To improve the amortized step complexity, backtracking can also be added to the search in the cleanup phase. Our modified cleanup phase is outlined in Figure 8. An empty local stack is initialized at the start of the cleanup, and is reused until the cleanup phase terminates. Nodes are pushed onto the stack when traversing the search path for k. When a violation is reached, a rebalancing attempt is performed. Regardless of whether this attempt succeeds or fails, a process backtracks to the first unmarked node on its stack before resuming its traversal to the leaf on the search path for k. A process performing BacktrackingCleanup is backtracking between the time when a node is popped from the stack on line 5 and when an unmarked node is found on line 6. If a process is not backtracking, it is looking for a violation. We divide an invocation I of BacktrackingCleanup(k) into a series of attempts. The first attempt of I begins when I is invoked, and all other attempts of I begin with backtracking. The last attempt of I ends on line 16 when a leaf is found, and all other attempts of I end on line 15. A process in its cleanup phase visits a node x if its local variable l in BacktrackingCleanup points to x. stack := new empty stack for pointers to nodes 3: while True do 4: if stack is empty then l := entry if l.info.state = InProgress then Help(l.info) 8: l := Pop(stack) 9: while True do 10: if l.w > 1 or (Top(stack).w = 0 and l.w = 0) then ⊲ Overweight or red-red violation at l if k < l.key then l := l.left else l := l.right ⊲ Search for leaf containing k

Bounding the Height of the Tree
Unlike insertions and deletions, rebalancing transformations do not change the keys of elements in the dynamic set and are not linearized. The original cleanup algorithm does has the property that all violations in the chromatic tree are eventually cleaned up by a process in its cleanup phase. This gives a height bound on the chromatic tree as a function of the number of active Insert or Delete operations. In this section, we show BacktrackingCleanup also has this property.
We first show basic properties about violations and the nodes on a process's local stack used for backtracking. A violation v is on a search path if v is located at a node on the search path. A violation v is reachable from a node x if one could follow child pointers starting from x and visit the node containing v. Lemma 5.7. A violation created during an Insert(k) or Delete(k) operation is on the search path for k until it is removed.
Proof. Recall that by inspection of Figure 6, only Insert and Delete transformations create violations. By inspection of Figure 5, if an Insert transformation adds a leaf with key k, or if a Delete transformation removes a leaf with key k, then any violations v created by the transformation are on the search path for k. By Lemma 4.5, v is on the search path for k until it is removed.
Lemma 5.8. Consider a node x in the chromatic tree that is on the search path for k in a configuration C. If x is reachable from a node y in the chromatic tree in C, then x is on the search path for k from y in C.
Proof. Since x is reachable from y, y is on the unique path of nodes in the chromatic tree from entry to x in C. So y is also on the search path for k in C. Since y appears before x on the search path for k in C, x is on the search path for k from y in C. Lemma 5.9. Let v be a node with weight 0. If v has a parent with non-zero weight at some point in an execution after v is added to the chromatic tree, then it does not gain a parent with weight 0.
Proof. Recall that weights are immutable. So the weight of v's parent can only change if its parent is replaced with a new node. By inspection of each chromatic tree transformation in Figure 5, if the parent of v is replaced with a new node with weight 0, then v's parent had weight 0 before the transformation.
Lemma 5.10. A node cannot gain violations while it is in the chromatic tree, and the only violation it can lose is a red-red violation, which occurs as the result of an update CAS.
Proof. Weights are immutable, so nodes cannot gain or lose overweight violations after they are added to the chromatic tree. By Lemma 5.9, a node with weight 0 that does not contain a red-red violation cannot gain a parent with weight 0. Thus, nodes do not gain violations while they are in the chromatic tree.
A node with weight 0 may lose a red-red violation if its parent with weight 0 is removed from the chromatic tree and replaced with a node with non-zero weight. Nodes are only removed from the chromatic tree as the result of an update CAS. Lemma 5.11. Any node on a process's stack in an invocation of BacktrackingCleanup(k) contains no violations.
Proof. Consider a node x pushed onto stack on line 17. Before any node is pushed onto stack, it must fail the check for violations on line 10. If x.w > 1, the check on line 10 will pass and so x will not be pushed onto stack. If x.w = 1, then x does not contain any violations. So suppose x.w = 0. Let y be the node pointed to by Top(stack) on line 10, where y.w = 0. By Observation 5.1.4, y was once a parent of x. Since x has a parent with non-zero weight 0 at some point, by Lemma 5.9, x cannot gain a parent with weight 0. Therefore, there are no violations at x.
Consider a chromatic tree transformation T that updates the pointer of a single node u, which removes a connected subtree of nodes R and replaces it with a new connected subtree of nodes A. The following facts follow by inspection of Figure 5: 1. The node u is in the chromatic tree before and after T .

2.
A node is removed from the chromatic tree if and only if it is a node in R.

A node is added to the chromatic tree if and only if it is a node in A.
4. If a node is reachable from u before T and is not a node in R, then the node is reachable from u after T . 5. If a node is reachable from u after T and is not a node in A, then the node was reachable from u before T . Definition 5.13. For any execution α, let its global graph, denoted G α = (V α , E α ), be a directed graph whose vertices are the union of nodes in the chromatic tree at all configurations in α. There is an edge from vertex x to vertex y if and only if y is the child of x sometime during α.
Lemma 5.14. For every execution α, G α contains no cycles.
Proof. We show by induction on the prefixes of the execution α that G α contains no cycles. Let φ denote the empty execution. G φ only contains the initial sentinel nodes, which do not form a cycle. Suppose α = α ′ s, where s is a step by some process. We assume G α ′ contains no cycles, and show G α contains no cycles.
The only step s that changes the structure of the chromatic tree is an SCX. Let u be the node whose pointer is updated by s, which removes a connect set of nodes R and replaces it with a new connected set of nodes A. Only nodes that were not in the chromatic tree in any prior configuration are added to the chromatic tree, and so Consider the edges in G α that were added by s. There is one edge from u to the root of A. No other edge in E α connects a node in V α ′ to a node in A. Besides the edges between nodes in A, the only other edges added by s are those from nodes in A to nodes in V α ′ .
If a path in G α only contains vertices in V α ′ , then by the induction hypothesis, this path does not form a cycle. If a path in G α only contains vertices in A, then since A is a tree, the path does not form a cycle. So consider a path containing both vertices in V α ′ and A. The path contains the edge from u to the root of A, since this is the only edge from a vertex in V α ′ to a vertex in A. Since A is a tree, the path can only form a cycle if it also passes through an edge connecting a vertex in A to a vertex in V α ′ . Let this edge be (x, y), where x ∈ A and y ∈ V α ′ .
Since A is a tree, there is an unique path from u to x in G α . By Observation 5.12.5, since y is reachable from u after s and y / ∈ A, there is a path from u to y in G α ′ . Therefore, since G α ′ contains no cycles, the path from u to y containing the edge (x, y) in G α does not form a cycle. Since no new path created by s creates a cycle, G α does not contain a cycle.
Consider any process P in its cleanup phase for key k. Let location(P, C) be the node pointed to by P 's local variable l in configuration C. We let P 's search path from r be the search path for k starting from the node r. If r is not mentioned, we assume the search path is starting from entry. Lemma 5.15. For every node x on P 's stack in configuration C during an execution α, there is a path in G α from x to location(P, C).
Proof. We prove by induction on the sequence of configurations of α. We assume the lemma holds for all configurations before an arbitrary step s, and show the lemma holds in the configuration C immediately after s. Let C − be the configuration immediately before C. In the initial configuration, there are no nodes on P 's stack, and so the lemma holds trivially. The types of steps s that affect the truth of lemma are those that update P 's local variable l, push nodes onto P 's stack, or pop nodes off P 's stack. For a process P in BacktrackingCleanup, such steps occur on lines 4, 5, 8, 11, 12, 17, and 18. (For a process P in BacktrackingSearch, the steps occur on lines 2, 3, 6, 8, 9, 10.) • Suppose s is a step that updates P 's local variable l to point to entry on line 4 (on line 3 for Backtrack-ingSearch). From the code, this only occurs when P 's stack is empty, so the lemma is vacuously true.
• Suppose s is a step that pops a node m off of P 's stack on line 5 or 8 (on line 3 or 6 for BacktrackingSearch).
Consider the configuration C m immediately before m was last pushed onto the stack. A node is only pushed onto P 's stack on line 17 (on line 8 for BacktrackingSearch) when pointed to by the local variable l, so location(P, C m ) = m. By definition of C m , the nodes on P 's stack are the same in C m and C. Since l is updated to the node popped by s, location(P, C) = m. By the induction hypothesis, for every node x on P 's stack in C m (and hence on P 's stack in C), there is a path in G α from x to location(P, C m ) = location(P, C).
• Suppose s is a step that pops a node m off of P 's stack on line 11 or 12 (on line 10 for BacktrackingSearch).
Since location(P, C − ) = location(P, C) and the nodes on P 's stack in C are a subset of those on P 's stack in C − , the lemma follows from the induction hypothesis.
• Suppose s is a step that pushes a node m onto P 's stack on line 17 (on line 8 for BacktrackingSearch). Let C − be the configuration immediately before C. Since location(P, C − ) = location(P, C), the induction hypothesis implies the lemma is true for all nodes on P 's stack in C except for m. Since location(P, C) = m, there is an empty path from m to location(P, C). Therefore, the lemma holds for all nodes on P 's stack in C.
• Suppose s is a step that updates P 's local variable l on line 18 (on line 9 for BacktrackingSearch). Let C − be the configuration immediately before C. From the code, l is updated to a child of l. Therefore, there is an edge in G α from location(P, C − ) to location(P, C). The nodes on P 's stack are the same in C − and C. By the induction hypothesis, for every node x on P 's stack in C, there is a path from x to location(P, C − ) in G α . Following the edge (location(P, C − ), location(P, C)), there is a path from x to location(P, C) in G α .
We use G α to prove some basic facts about the ordering of nodes on a process's local stack used during backtracking.
Lemma 5.16. If a node x is on a process P 's stack in configuration C, then x is not reachable from location(P, C).
Proof. By the Lemma 5.15, there is a path from x to location(P, C) in G α . If x is reachable from location(P, C), this implies there is a path from location(P, C) to x in G α . This contradicts Lemma 5.14, which states that G α contains no cycles. Therefore, x is not reachable from location(P, C).
Notice that backtracking in BacktrackingCleanup(k) is performed in the same manner as in Backtrack-ingSearch(k, stack). Therefore, the proof of Lemma 5.4 also shows that a node x visited by Backtracking-Cleanup(k) was on the search path for k in some earlier configuration.
Corollary 5.17. (of Lemma 5.4) Consider an instance I of BacktrackingCleanup(k) in an attempt A, and let C be a configuration during A sometime after backtracking. Let C ′ be the configuration immediately after the last node popped during the backtracking in A, or the configuration after the start of A if no such pop occurred. If x is the node pointed to by I's local variable l in C, then there is a configuration between C ′ and C in which x is on the search path for k.
Lemma 5.18. In any configuration C, any node on the stack of a process performing BacktrackingCleanup(k) (or BacktrackingSearch(k, stack)) that is in the chromatic tree is on the search path for k in C.
Proof. Since x is on the stack in C, x was pushed onto the stack in some configuration before C. Only nodes pointed to by a process's local variable l are pushed onto its stack on line 17 of BacktrackingCleanup or on line 8 of BacktrackingSearch. Hence, by Corollary 5.17 (or Lemma 5.4 for BacktrackingSearch), x was on the search path for k in some configuration before C. Therefore, since x is in the chromatic tree in C, by Lemma 5.3, x is on the search path for k in C. Lemma 5.19. In any configuration C, any unmarked node on the stack of a process performing Backtracking-Cleanup(k) (or BacktrackingSearch(k, stack)) is on the search path for k in C.
Proof. By Observation 5.1.3, x was once in the chromatic tree. Since x is unmarked in C, by Lemma 5.2, x is still in the chromatic tree in C. By Lemma 5.18, x is on the search path for k in C.
Lemma 5.20. Consider two nodes x and y on a process's stack in configuration C during an instance of Back-trackingCleanup(k) (or BacktrackingSearcg(k, stack)) that are in the chromatic tree. If x appears above y on the stack in C, then x is on the search path for k from y in C.
Proof. By Observation 5.1.4, there is a path from y to x in G α . By Lemma 5.18, both x and y are on the search path for k from entry. If x is not on the search path for k from y, then y is on the search path for k from x. This implies there is a path from x to y in G α , which forms a cycle. By Lemma 5.14, G α contains no cycles, and so x is on the search path for k from y in C. Lemma 5.21. Consider a process P in its cleanup phase in configuration C. Let m be any unmarked node on P 's stack in C. If a violation v is on P 's search path from location(P, C), then v is on P 's search path from m.
Proof. By Lemma 5.19, m is on P 's search path in C. Suppose m appears after v on P 's search path. Since v is on P 's search path from location(P, C), so is m. This contradicts Lemma 5.16, which states that m is not reachable from location(P, C). Therefore, v occurs after m on P 's search path, and so v is on P 's search path from m.
Next we prove some basic facts about how violations are moved after a rebalancing transformation T . Inspection of how violations are created, removed, or moved by T according to Figure 6 gives the following facts. Observation 5.22. Consider an chromatic tree transformation T that updates the pointer of a single node u, which removes a connected subtree of nodes R and replaces it with a new connected subtree of nodes A.
1. Every violation moved by T is moved to a node in A.
2. Every violation located at a node in R is either moved to a node in A or removed.
3. A BLK transformation centered at a node x that elevates the red-red violation v located at x moves v from x to a node in A, where x / ∈ R is a child of a node in R. Every other transformation only moves violations located at nodes in R. Lemma 5.23. Let x be any node, not necessarily in the chromatic tree. Consider a chromatic tree transformation T that does not move or remove violation v. If v is on the search path for a key k from x before T , then v is on the search path for k from x after T .
Proof. Consider the node u whose pointer is updated by T . If u is not on the search path for k from x, then no pointer along the path from x to the node containing v is changed. Since v is not moved, it is located at the same node before and after T . Therefore, v is on the search path for k from x after T .
If u is on the search path for k from x, then by Observation 5.12.4, the nodes reachable from u before T are reachable from u after T , except for the nodes R removed by T . So only nodes in R are removed from the search path for k from x. By Observation 5.22.2, every violation in R is either moved or removed. Since v is not moved or removed, it is not located at a node in R, and so v is still on the search path for k from x after T .
The following lemma is a generalized version of Lemma 4.5 that applies to search paths starting from nodes in the chromatic tree other than entry.
Lemma 5.24. Consider any node x with no violations that is in the chromatic tree before and after a transformation T . If violation v is on the search path for key k from x before T , then v is still on the search path for k from x after T , or has been removed.
Proof. Let C − be the configuration immediately before T , and C be the configuration immediately after T . Let u be the node whose pointer is updated by T , R be the nodes removed by T , and A be the nodes added by T . By Lemma 5.23, if v is not moved by T , then v is on the search path for k from x in C.
So suppose v is moved by T . Then it moves from a node r to a new node r ′ , where r ′ ∈ A by Observation 5.22.1. By Observation 5.22.3, either r ∈ R or r is a child of a node in R. By inspection of Figure 5, every node in R is reachable from u in C − , so there is a path from u to r in C − . Since both x and u are in the chromatic tree, they are both on the path from entry to r in C − .
We argue x is an ancestor of u in C − . By assumption, x contains no violations in C − , so x = r. Since r ∈ R or r is a child of a node in R, and the nodes in R are connected, it follows that all nodes on the path from u to the parent of r except for u are in R. By Observation 5.12.2, the nodes on this path are removed from the chromatic tree by T . Since x is not removed from the chromatic tree by T , x is an ancestor of u in C − .
The path of nodes from entry to u are unmodified by T , so x is an ancestor of u in C. By Lemma 5.7, r ′ is still on the search path for k in C. Since r ′ ∈ A, r ′ is reachable from u in C, and so r ′ is reachable from x in C. Therefore, by Lemma 5.8, v is on the search path for k from x in C.
The next lemma informally states that for every violation v in the chromatic tree in a configuration C, either its creator P contains v on its search path starting from location(P, C), or P will backtrack to a node such that v is on the search path from that node. Lemma 5.25. In every configuration C, and for every violation v in the chromatic tree in C, the creator P of v is in the cleanup phase, and one of the following two conditions are true: (A) P is looking for a violation, and either 1. P 's search path from location(P, C) contains v, or 2. P 's search path from the first unmarked node on P 's stack contains v, and either P will find a violation on line 10 before pushing an unmarked node onto its stack in a solo run from C, or has already found a violation on line 10 in its current attempt, or (B) P is backtracking, and either 1. P 's search path from location(P, C) contains v, and location(P, C) is unmarked, or 2. P 's search path from the first unmarked node on its stack contains v, and location(P, C) is marked.
Proof. We assume the lemma holds for all violations in the configuration C before a step s taken by a process Q, and show the lemma holds for all violations in the configuration C ′ immediately after s. In the initial configuration, there are no violations in the chromatic tree, so the lemma holds trivially in the base case.
Consider an arbitrary violation v in C that was created by a process P . If the step s by Q only changes its local state, then the invariant can only be falsified for v if Q = P . The only changes to P 's local state that affect the truth of the invariant for v are those that change P 's local variable l, modify P 's local stack, cause P to stop backtracking, or cause P to stop looking for a violation. Such changes occur on lines 4, 5, 11, 17 and 18, when reading that location(P, C) is unmarked on line 6, or when reading that location(P, C) is a leaf on line 16.
The other possibility is that s is a successful SCX from an invocation of TryInsert, TryDelete, TryRebalance, or Help. In this case, s may affect the truth of the invariant for all violations.
We consider each type of step s and argue (A) or (B) is satisfied for each violation in C ′ .
• Case 1: Suppose s is a step by P that sets the local variable l to entry on line 4. By Observation 5.1.2, backtracking never pops from an empty stack, so P must be entering the cleanup phase after creating a violation v in its update phase. By Lemma 5.7, a violation created by P is on the search path for P starting from entry. Therefore, (A1) is true for v in C ′ .
• Case 2: Suppose s is a step by P that updates the local variable l on line 5 by popping from the stack. By definition, P is looking for a violation in C, and is backtracking in Let m be the first unmarked node on P 's stack in C. We argue v is on P 's search path from m in C ′ . If (A1) is true for v in C, then by Lemma 5.21, v is on P 's search path from m in C. If (A2) is true for v in C, then by the induction hypothesis, v is on P 's search path from m in C. In either case, since s does not modify the chromatic tree, v is on P 's search path from m in C ′ .
If the node popped by s is m, then m = location(P, C ′ ). By definition of m, location(P, C ′ ) is unmarked and v is on P 's search path from location(P, C ′ ) in C ′ , so (B1) is true for v in C ′ . If the node popped by s is not m, then location(P, C ′ ) is a marked node and m is still the first unmarked node on P 's stack in C ′ . Therefore, so (B2) is true for v in C ′ .
• Case 3: Suppose s is a step by P that reads location(P, C) is unmarked on line 6, which causes P to stop backtracking. Thus (B) is true for v in C. Since location(P, C) is unmarked, (B2) is false for v in C, so (B1) is true in C. Therefore, v is on P 's search path from location(P, C). Since location(P, C ′ ) = location(P, C) and P is looking for a violation in C ′ , (A1) is true for v in C ′ .
• Case 4: Suppose s is a step by P that updates the local variable l by the pop on line 8. Then P is backtracking in both C and C ′ . The last check on line 6 saw that location(P, C) was marked, and so (B2) is true for v in C. Let m be the first unmarked node on P 's stack in C. By the induction hypothesis, v is on P 's search path from m in C. Since s does not modify the chromatic tree, v is on P 's search path from m in C ′ .
If the node popped by s is m, then m = location(P, C ′ ). By definition of m, location(P, C ′ ) is unmarked and v is on P 's search path from location(P, C ′ ) in C ′ , so (B1) is true for v in C ′ . If the node popped by s is not m, then location(P, C ′ ) is a marked node and m is still the first unmarked node on P 's stack in C ′ . Therefore, so (B2) is true for v in C ′ .
• Case 5: Suppose s is a step by P that pops from P 's stack on line 11 or 12. Then P is looking for a violation in C and C ′ . Note that s does not modify v or P 's local variable l, so if (A1) is true for v in C, then (A1) is true for v in C ′ .
So suppose (A2) is true for v in C. Let m be the first unmarked node on P 's stack in C, and m ′ be the first unmarked node on P 's stack in C ′ . (Note that either m = m ′ , or m ′ is the second unmarked node on P 's stack in C.) By Lemma 5.19, both m and m ′ are on P 's search path in C. By Lemma 5.20, m is on the P 's search path from m ′ in C. By the induction hypothesis, v is on P 's search path from m in C. Therefore, v is on P 's search path from m ′ in C. Since s does not modify the chromatic tree, v is on P 's search path from • Case 6: Suppose s is a step by P where P reads that location(P, C) is a leaf, causing P to exit its cleanup phase on line 16. By the check on line 10 and Lemma 5.10, there are no violations at location(P, C). Since P is looking for a violation, and there are no violations on P 's search path from location(P, C), P does not satisfy (A) for any violation the chromatic tree in C. By the induction hypothesis, the lemma is true in C, so P cannot be the creator of any remaining violation in the chromatic tree in C. Since step s does not create a violation, s cannot falsify the lemma.
• Case 7: Suppose s is a step by P that pushes a pointer to location(P, C) onto P 's stack on line 17. Since P is looking for a violation in both C and By the induction hypothesis, P does not push an unmarked node onto its stack until after finding a violation on line 10. Since s is the first step in its solo execution, location(P, C) is a marked node and is pushed onto the stack by s. Therefore, neither condition of (A2) can be falsified by s, and so (A2) is true for v in C ′ .
• Case 8: Suppose s is a step by P that updates the local variable l on line 18. Since P is looking for a violation in C, (A) is true for v in C.
Suppose (A1) is true for v in C, so v is on P 's search path from location(P, C). In the previous step by P , location(P, C) was pushed onto the stack, and so by Lemma 5.11,there is no violation at location(P, C). From the code, s changes l to point to the next node on its search path. Since v is not at location(P, C), v is on P 's search path from location(P, C ′ ). Therefore (A1) is true for v in C ′ .
If (A2) is true for v in C, then P takes the first step in its solo execution from C. Since s does not push a pointer to a node onto the stack, neither condition of (A2) can be falsified by s, so (A2) is true for v in C ′ .
• Case 9: Suppose s is a successful SCX of any chromatic tree transformation performed by some process Q.
Let u be the node whose pointer is updated by s, R be the set of nodes removed from the chromatic tree by s, and A be the set of nodes added to the chromatic tree by s.
The invariant cannot be falsified by any violations removed by s. If a new violation is created by s while performing an Insert or Delete transformation, then Q enters the cleanup phase starting from entry, and so (A1) is true for the new violation in C ′ .
So consider a violation that is not created or removed by s (so it is either moved or unmodified by s).
Let v be this violation, whose creator is P . Since s does not update P 's local variable l, location(P, C) = location(P, C ′ ). We consider multiple cases, depending on whether (B1), (B2), (A2) or (A1) is true for v in C.
is in the chromatic tree in both C and C ′ . Since P is backtracking in C, location(P, C) was previously popped from the stack. By Lemma 5.10 and Lemma 5.11, there are no violations at location(P, C) in C. By the induction hypothesis, v is on P 's search path from location(P, C) in C. Therefore, by Lemma 5.24, v is on P 's search path from location(P, Otherwise location(P, C) is marked in C ′ and so (B1) is false for v in C ′ . Let m ′ be the first unmarked node on P 's stack in C ′ . By the induction hypothesis, v is on P 's search path from location(P, C) in C, so by Lemma 5.21, v is on P 's search path from m ′ in C. By Lemma 5.11, m ′ does not contain any violations, and by Lemma 5.2, m ′ is in the chromatic tree in C ′ . Therefore, by Lemma 5.24, v is on P 's search path from m ′ in C ′ . Therefore, (B2) is true for v in C ′ .
-Suppose (B2) is true for v in C. Let m be the first unmarked node on P 's stack in C, and let m ′ be the first unmarked node on P 's stack in C ′ . Note that m = m ′ if s does not remove m from the chromatic tree. By Lemma 5.20, m is on P 's search path from m ′ in C. By the induction hypothesis, v is on P 's search path from m in C. Therefore, v is on P 's search path from m ′ in C. By Lemma 5.10 and Lemma 5.11, there are no violations at location(P, C). Therefore, by Lemma 5.24 By the induction hypothesis, there is a path of marked nodes on P 's search path from location(P, C) to a node where P will fail the check on line 10 if run solo from C. The pointers of marked nodes cannot be modified, so this path of marked nodes is not modified by s. So the second condition of (A2) remains true after s. Let m be the first unmarked node on P 's stack in C, and m ′ be the first unmarked node on P 's stack in C ′ . By Lemma 5.20, m is on P 's search path from m ′ in C. By the induction hypothesis, v is on P 's search path from m in C. Therefore, v is on P 's search path from m ′ in C. By Lemma 5.2, m ′ is in the chromatic tree in C and C ′ , and by Lemma 5.11, m ′ contains no violations. Therefore, by Lemma 5.24, If s does not move v, then by the induction hypothesis and Lemma 5.23, v is on the search path for P from location(P, So suppose v is moved by s from a node r to a node r ′ , where r ′ ∈ A by Observation 5.22.1. Let nextLoc(P, C) be the first node on P 's search path from location(P, C) that is in the chromatic tree in C. Note that if location(P, C) is in the chromatic tree in C, then nextLoc(P, C) = location(P, C). By definition, violations are located at nodes in the chromatic tree, so r is in the chromatic tree in C. By the induction hypothesis, r is on P 's search path from location(P, C) in C. Hence, r is on P 's search path from nextLoc(P, C) in C.
Consider the unique path of nodes in the chromatic tree on P 's search path from entry to r in C. Since nextLoc(P, C) is in the chromatic tree, nextLoc(P, C) is a node on this path. By Observation 5.22.3, r ∈ R or r is a child of a node in R, and since each node in R is reachable from u, u is also a node on this path. Suppose nextLoc(P, C) is an ancestor of u in C, then s does not modify any nodes on the path from nextLoc(P, C) to u. So nextLoc(P, C) is an ancestor of u in C ′ . Since r ′ is reachable u, and u is reachable from nextLoc(P, C), it follows from Lemma 5.8 that r ′ is on P 's search path from nextLoc(P, C) in C ′ . The nodes on the path from location(P, C) to nextLoc(P, C) are unmodified by s because fields of nodes not in the chromatic tree do not change. So v is on P 's search path from location(P, C) in C ′ , and (A1) is true for v in C. So suppose nextLoc(P, C) is a proper descendant of u. Then nextLoc(P, C) is a node on the path from u to r (excluding u) in C. We first argue the second condition of (A2) is true for v in C ′ . By Observation 5.22.3, either r ∈ R or r is a child of a node in R. By Observation 5.12.2 and the fact that the nodes in R are connected, all nodes on the path from u to the parent of r (excluding u) are removed from the chromatic tree. Therefore, all nodes from nextLoc(P, C) to r's parent are marked in C ′ . If P has not already found a violation on line 10 in its current attempt, P will only push marked nodes onto its stack in a solo run in C ′ until it visits r, or it finds a violation before reaching r. Note that if P visits r in its solo run in C ′ , the check on line 10 will evaluate true and P will not push r onto its stack. If r was an overweight violation in C, then P will find r.w > 1 on line 10. If r was a red-red violation in C, then by Lemma 5.9, all nodes with child pointers pointing to r have weight 0. Therefore, P will find a red-red violation on line 10 since r.w = 0 and the last node pushed onto P 's stack before reaching r has weight 0. Since P will only push marked nodes onto its stack before finding a violation on line 10, the second condition of (A2) is satisfied in C ′ .
To show the first condition of (A2) is true for v in C ′ , let m ′ be the first unmarked node on P 's stack in C ′ . By the induction hypothesis, v is on P 's search path from location(P, C) in C, so by Lemma 5.21, v is on P 's search path from m ′ in C. By Lemma 5.11, m ′ contains no violations in C. Therefore, by Lemma 5.24, v is on P 's search path from Therefore, for any violation v in the chromatic tree in C ′ , either condition (A) or (B) is satisfied. The lemma follows by induction.
The next result follows from Lemma 5.25 together with the fact that each operation creates at most 1 violation in its update phase, and none in its cleanup phase.
Corollary 5.26. The number of violations in the chromatic tree is bounded by the number of incomplete Insert and Delete operations.
Using Corollary 5.26, it is shown that the following theorem holds [4]. Theorem 5.27. If there are c incomplete Insert and Delete operations and the data structure contains n keys, then its height is O(c + log n).

Chromatic Tree Amortized Analysis
In this section, we prove the amortized step complexity of the chromatic tree is proportional to the height of the tree plus the point contention of the execution. The structure of our proof is similar to the amortized step complexity of a binary search tree by Ellen et al [6]. We first divide the steps taken by an operation op by those taken in its update phase up and cleanup phase cp. The total steps taken by a process for an operation op is then steps(op) = steps(up) + steps(cp).
We divide the steps further by expressing steps(up) and steps(cp) as a function of the number of attempts and the number of pushes performed for up and cp respectively. • attempts(up) be the number of times up performs TryInsert or TryDelete during its execution interval, • attempts(cp) be the number of times cp performs TryRebalance during its execution interval, • pushes(up) be the number of times up performs Push across all of its calls to BacktrackingSearch, and • pushes(cp) be the number of times cp performs Push during BacktrackingCleanup. Proof. First we consider the number of steps taken in the subroutines TryInsert, TryDelete, and TryRebalance. These subroutines each perform a constant number of LLXs, followed by a single SCX. From the code, an invocation of SCX(V, R, f ld, new) takes O(1) steps, since |V | ≤ 6 for all chromatic tree transformations. It also follows from the code that an LLX takes O(1) steps. Therefore, a single invocation of TryInsert, TryDelete, or TryRebalance takes O(1) steps. By definition, the number of times up performs TryInsert or TryDelete is attempts(up), and so the total number of steps taken is O(attempts(up)). Similarly, the total number of steps taken during all instances of TryRebalance invoked by cp is O(attempts(cp)).
All that remains is to count the number of steps taken by searches during the update and cleanup phases. Let pops(up) and pops(cp) be the number of times op performs Pop when backtracking across all its calls to BacktrackingSearch and BacktrackingCleanup respectively. Every call of Pop during backtracking is performed on a non-empty stack by Observation 5.1.2. Therefore, pops(up) ≤ pushes(up) and pops(cp) ≤ pushes(cp). It is therefore sufficient to count the number of pushes made during up and cp. By definition, this number is pushes(up) for up, so the total number of steps taken during all instances of BacktrackingSearch invoked by up is O(pushes(up)). Likewise, the total number of steps taken during the instance of BacktrackingCleanup invoked by cp is O(pushes(cp)). The lemma follows by adding the steps taken by the update phase and cleanup phase of an operation.
In order to express the step complexity of operations for the chromatic tree, we use the following notions of height. Definition 6.3. For each configuration C and operation op with update phase up and cleanup phase cp of an execution α, let: • h(C) be the height of the chromatic tree in configuration C, • h(up) and h(cp) be the height of the chromatic tree in the starting configuration of up and cp respectively, and • h(op) be the maximum height of the chromatic tree over all configurations during the execution interval of op.
For each operation op with update phase cp and cleanup phase cp in an execution α, letċ(up) andċ(cp) be the maximum number of active operations in a single configuration during the execution interval of up and cp respectively. Let viol(cp) be the violation created by up, or Nil if up did not create a violation. Several rebalancing transformations may be applied to a violation v before it is removed. For a particular violation v in an execution α, let rebal(v) be the number of times v is located at the center of a successful rebalancing transformation in α.
Let rebal(Nil) = 0. In Section 6.1, we will prove that for any finite execution α, Section 6.2 is devoted to showing that for any finite execution α, Combining these main results from Section 6.1 Section 6.2 with Lemma 6.2 gives the following lemma. The height terms h(up) and h(cp) in Lemma 6.4 can be interpreted as the steps required to traverse the chromatic tree during searches in the update phase and cleanup phase respectively. Theċ(up) terms account for extra steps taken by operations concurrent with up due to the successful insertion or deletion made by up. Similarly, the rebal(viol(cp)) ·ċ(cp) terms account for extra steps taken due to successful rebalancing transformations centered at viol(cp). Lemma 6.4 and Theorem 4.3 together prove the main theorem of our paper.
So, the total number of steps taken by all operations in an execution α is It follows that the amortized step complexity of a single operation op is O(h(op) +ċ(α)). By Theorem 5.27, this can be expressed as O(ċ(α) + log n(op)).
Notice that the amortized cost of each operation has an additive term of O(ċ(α)), as opposed to O(ċ(op)). This is because the operation with the largest contention in the execution may perform the majority of rebalancing. Theorem 4.3 only gives an upper bound on the total number of rebalancing transformations that may occur in an execution, but does not state anything about which operations will perform these rebalancing transformations.

Bounding the Number of Pushes
In this section we provide an upper bound on pushes(up) and pushes(cp). To do so, we classify all pushes into one of three categories, depending on properties of the node that was pushed onto the stack. We use an aggregate analysis to give separate bounds on the number of pushes that can occur for each category. Definition 6.6. We classify instances of Push during BacktrackingSearch (or BacktrackingCleanup) for the update phase up (or cleanup phase cp) of an operation into three categories: • Category 1: -The node pushed is later popped on line 10 in some instance of BacktrackingSearch invoked by up, or the last node popped on line 3 or 6 in a later instance of BacktrackingSearch invoked by up, or the node pushed is later popped on line 11 or 12 in cp's instance of BacktrackingCleanup, or the last node popped on line 5 or 8 in a later attempt of BacktrackingCleanup.
• Category 2: A push of a node x that is not in Category 1, and x is in the chromatic tree for all configurations during the execution interval of up (or cp).
• Category 3: A push of a node x that is not in Category 1, and x is not in the chromatic tree in some configuration during the execution interval of up (or cp).
Every push is in exactly one of these three categories. Category 1 pushes are of nodes that are later popped to be passed as arguments into TryInsert, TryDelete, or TryRebalance, or are of nodes that are the last nodes popped during backtracking in attempts. We will show that a Category 1 push is the only type of push that may push the same node onto the same stack twice in a phase. Category 2 pushes are of nodes that are not popped off the stack. Category 3 pushes are those that are performed on nodes added or removed from the chromatic tree by concurrent operations. Proof. Consider an operation op with update phase up and cleanup phase cp. In each invocation of Backtrack-ingSearch for up, there is at most 1 node that is the last node popped when backtracking, and at most 1 node popped on line 10. So there are at most 2 · attempts(up) Category 1 pushes by up during its invocations of BacktrackingSearch.
Similarly for BacktrackingCleanup, there is at most 1 node that is the last node popped during backtracking per cleanup attempt. Additionally, each cleanup attempt will pop a total of at most 2 nodes on lines 11 and 12. So there are at most 3 · attempts(cp) Category 1 pushes by cp during its invocation of BacktrackingCleanup. The lemma follows from taking the sum of Category 1 pushes over all update and cleanup phases in an execution α.
The following properties of the implementation of LLX and SCX used in the chromatic tree were proven in [3].
1. Suppose a successful mark step mstep belonging to an SCX-record U on r occurs. Then r is frozen for U when mstep occurs, and forever after.
2. There cannot be both a frozen step and an abort step belonging to the same SCX-record.
3. Suppose a frozen step is performed for U . Then a commit step is performed for U before any invocation of Help(ptr) terminates, where ptr is a pointer to U .
The above properties are used in the following lemma. Proof. We prove the case for when xp is an update phase. The case for when xp is a cleanup phase follows similarly. Let U be the SCX-recorded pointed to by x.info when x was marked. By Observation 6.8.1, x.info points to U in all configurations after this point, so x.info points to U when xp reads x.info.state on line 5. From the code of LLX, if a mark step belonging to U is performed, then a frozen step belonging to U has been performed. By Observation 6.8.2, an abort step does not belong to U , and so U is not in the Aborted state when xp reads x.info.state on line 5. So xp either reads x.info.state is either InProgress or Committed. In either case, we argue there exists a configuration C during A in which x is marked and x.info points to a Committed SCX-record.
If xp reads that U is in the Committed state, let C be the configuration immediately after the read. If xp reads that U is in the InProgress state, then xp executes Help(x.info) on line 5. By Observation 6.8.3, a commit step belonging to U is performed before this invocation of Help terminates. Let C be the configuration immediately after this commit step. In configuration C, x is marked and x.info points to a Committed SCX-record, and so by definition is not a node in the chromatic tree. Lemma 6.10. Suppose an update or cleanup phase xp pushes a node x onto its stack, and this push is not Category 1. If x is later popped off the stack, then before the next pop by xp, x is not in the chromatic tree.
Proof. Since x is not pushed onto the stack by a Category 1 push, it is popped during backtracking. By definition, x is not the last node popped during backtracking. Therefore, when xp next executes line 4 of BacktrackingSearch (or 6 of BacktrackingCleanup), xp will read that x is marked. By Lemma 6.9, x is not a node in the chromatic tree in some configuration before the next pop by xp. Lemma 6.11. In each of an operation op's update and cleanup phases, op pushes a node onto its stack at most once by a Push that is not a Category 1 push.
Proof. Suppose, for contradiction, that a particular node x is pushed onto the stack twice during an update phase or cleanup phase xp by two pushes push 1 and push 2 that are not in Category 1. Without loss of generality, assume push 1 occurs before push 2 . Only the node pointed to by xp's local variable l is pushed onto the stack. Hence by Lemma 5.16, x is not on xp's stack in the configuration immediately before push 2 . Therefore, x is popped off the stack between push 1 and push 2 . By Lemma 6.10, x is not in the chromatic tree before the next pop by xp.
Let C ′ be the configuration immediately after the last pop during backtracking in the attempt containing push 2 . By definition, x is not the last node popped during backtracking of some attempt, so at least 1 other node has been popped by xp since the time x was popped. Therefore, x is not in the chromatic tree in C ′ .
In the configuration C immediately before push 2 , xp's local variable l points to x. Lemma 5.4 (or Corollary 5.17 when xp is a cleanup phase) implies x is on xp's search path in a configuration between C ′ and C. Thus, x is reachable from entry, which contradicts the fact that x is not in the chromatic tree in C ′ .
The next lemma informally states that a rebalancing transformation cannot cause a node x to gain an ancestor that was already a node in the chromatic tree before the transformation. Lemma 6.12. Let C be the first configuration in which two nodes x and y are both in the chromatic tree. If x is the descendant of y in a configuration C ′ after C, then x is the descendant of y in all configurations between C and C ′ .
Proof. We prove by backwards induction on the sequence of configurations between C and C ′ . We assume x is a descendant of y in C ′ after a step s, and show x is a descendant of y in the configuration C − immediately before The only type of step s that changes the structure of the chromatic tree is the update CAS of some SCX. Let u be node whose child pointer is updated by s, which removes a connected set of nodes R from the chromatic tree, and adds a connected set of nodes A to the chromatic tree. Note that since nodes removed from the chromatic tree are not added back to the chromatic tree, x and y are in the chromatic tree in all configurations between C and C ′ .
Note that x and y are not in A, otherwise Observation 5.12.3 implies they are added to the chromatic tree by s and so x and y were not in the chromatic tree in C − . Additionally, x and y are not in R, otherwise Observation 5.12.2 implies they are removed from the chromatic tree by s, and so x and y are not in the chromatic tree in C ′ .
By Observation 5.12.1, u is in the chromatic tree in both C − and C ′ , so we consider multiple cases depending on the location u in the chromatic tree relative to x and y. In particular, we consider the cases when u is a proper ancestor of both x and y, a proper ancestor of x but not a proper ancestor of y, or a proper ancestor of neither x nor y.
• Suppose u is not a proper ancestor of x or y in C ′ . Since s only modifies nodes in the subtree rooted at u, the path from x to y in C ′ is not altered by the step s. Thus x is the descendant of y in C − .
• Suppose u is a proper ancestor of x, but not a proper ancestor of y in C ′ . So u is on the path from y to x in C ′ . Since s does not modify the pointers of any nodes that are proper ancestors of u, there is a path from y to u in C − . By Observation 5.12.5, since x is reachable from u in C ′ and x / ∈ A, x is reachable from u in C − . Therefore, x is a descendant of y in C − .
• Suppose u is a proper ancestor of both x and y. By Observation 5.12.5, since x and y are reachable from u in C ′ and x, y / ∈ A, x and y are reachable from u in C − . Consider the path of nodes from y to x in C ′ . Since x and y are not nodes in the sets R and A, and the fact that R and A are connected sets of nodes, all nodes on this path are in the chromatic tree in C − and C ′ . Since s does not modify the child pointers of any of these nodes, x is a descendant of y in C − . Lemma 6.13. The number of Category 2 pushes in an execution α is at most Proof. Consider an update phase or cleanup phase xp of an operation. Let C ′ be the last configuration of xp, and C be the first configuration of xp. Any node pushed onto xp's stack by a Category 2 push is in the chromatic tree from C to C ′ , and hence by Lemma 6.10, is not popped off the stack. Consider the nodes pushed onto xp's stack by a Category 2 push in C ′ . By Lemma 5.18, each of these nodes are on xp's search path in C ′ . Let x 1 , . . . , x m be the order in which these nodes appear on this path, where x i+1 is a descendant of x i , for 1 ≤ i < m. Since x i and x i+1 are both in the chromatic tree in C, by Lemma 6.12, x i+1 is a descendant of x i in C. Since there are at most h(xp) internal nodes on a single path in the chromatic tree in C, Lemma 6.11 implies there are at most h(xp) Category 2 pushes during xp.
Proof. Consider the update phase or cleanup phase xp of some operation. Nodes on the stack from Category 3 pushes are not in the chromatic tree at some point during xp, so they are either removed or added to the chromatic tree after xp begins. Nodes can only become reachable or unreachable after an update CAS of a successful SCX. We charge each Category 3 push made by xp to the update or cleanup phase that performed this update CAS.
First consider an update CAS for an Insert or Delete transformation by an update phase up. An Insert causes at most 3 nodes to become reachable and 1 unreachable. A Delete causes 1 node to become reachable and 3 nodes to become unreachable. This causes every process concurrent with up to perform at most 4 Category 3 pushes. By Lemma 6.11, each of these Category 3 pushes occur at most once, so at most 4ċ(up) Category 3 pushes are charged to the update CAS by up.
Next we consider Category 3 pushes that result from the update CASs of rebalancing transformations. Consider an update CAS of a rebalancing transformation centered at a node with violation v in configuration C. It makes at most 5 nodes reachable and 5 nodes unreachable (for example, when the rebalancing transformation is W3). Then at most 10ċ(C) Category 3 pushes are made among theċ(C) active operations. We charge these 10ċ(C) pushes to the cleanup phase cp of the operation whose update phase created the violation (i.e. viol(cp) = v). Since C is in the execution interval of cp, it follows by definition that 10ċ(C) ≤ 10ċ(cp). Recall that the number of times a rebalancing transformation is centered at v in an execution α is rebal(v). So the total amount charged to cp throughout α is at most 10ċ(cp) · rebal(viol(cp)). The total number of Category 3 pushes made in α is therefore at most up∈α 4ċ(up) + cp∈α 10ċ(cp) · rebal(viol(cp)). Lemma 6.15. For any finite execution α, Proof. Every push performed by an operation op in α is either Category 1, Category 2, or Category 3. Adding the upper bounds established in Lemmas 6.7, 6.13, and 6.14 gives an upper bound on the number of pushes during update and cleanup phases in any finite execution α.

Bounding the Number of Attempts
All that remains in the amortized analysis is to give an upper bound on attempts(up) and attempts(cp) for each operation in any finite execution. Recall that an attempt of an update phase begins with backtracking, and ends after a successful or unsuccessful TryInsert or TryDelete. An attempt of a cleanup phase begins with backtracking, and ends after a TryRebalance or if a leaf node with no violations is reached. In this section, we show the following main lemma.
As described in Section 3, the amortized analysis for counting attempts is difficult when failed attempts can cause failures. This happens for updates done using LLX and SCX. For example, consider an invocation S of SCX for an operation op, where two nodes are required to be frozen for S before the update CAS for S is performed. If the first freezing CAS for S on a node x succeeds, S can cause all concurrent SCX operations that perform freezing CASs on x to fail. If the second freezing CAS for S fails, S performs an abort step that unfreezes x and returns False. Operation op has now caused a number of concurrent operations to fail without making any progress on completing its own operation. This argument can be extended to show that an operation can cause an unbounded number of failed attempts. Therefore, we cannot charge op for all the failed attempts it causes.
Our analysis for counting the number of attempts made in the update phase closely follows the analysis done in [6], but differs when counting the number of rebalancing attempts in the cleanup phase. As mentioned in the introduction, several factors make this more challenging. It was shown by Boyar and Larsen that removing a particular violation may require a number of rebalancing transformations proportional to the height of the chromatic tree [1]. Thus, the number of rebalancing transformations centered at the violation created by an operation may be large. Additionally, a process may take several failed attempts that try to remove a violation on its search path only to have a different process perform the successful rebalancing transformation to remove it. The rebalancing transformation needed to cleanup a violation may change as concurrent processes make nearby changes to the chromatic tree. Finally, violations can be moved onto a process's search path in the middle of its cleanup phase. We show how to extend the amortized analysis techniques used in [6] to circumvent these issues.

Counting Successful Attempts
Our analysis for counting the number of attempts performed in the update phase and cleanup phase of an operation is divided into counting successful and unsuccessful attempts, where attempts(up) = successfulAttempts(up) + failedAttempts (up) and attempts(cp) = successfulAttempts(cp) + failedAttempts(cp).
Recall that an invocation of TryInsert, TryDelete, or TryRebalance is successful if a successful SCX is performed. The invocation is unsuccessful if it fails an LLX, SCX, or Nil check. We first count the number of successful attempts in an execution. Proof. For every completed update phase of an operation, there is exactly 1 successful attempt, which is always the last attempt of the update phase. Therefore, there are at most i + d successful attempts of TryInsert and TryDelete.
By Theorem 4.3, at most 3i + d − 2 successful rebalancing transformations are sufficient to remove all violations from the chromatic tree. This corresponds to at most 3i + d − 2 successful invocations of TryRebalance across the cleanup phases in an execution.

Overview of the Accounting Method For Counting Failed Attempts
In this section, we give upper bounds on f ailedAttempts(up) and f ailedAattempts(cp). Recall that a failed invocation of TryInsert, TryDelete, or TryRebalance is one that fails an LLX, SCX, or Nil check. Failures due to Nil checks can be handled separately and are explained in Section 6.2.9. The majority of the analysis will be for counting the number of failed attempts due to failed LLXs and SCXs.
Our analysis follows the accounting method. We use 2 types of bank accounts, one associated with update phases up and one associated with cleanup phases cp. The rules that deposit and withdraw dollars from bank accounts are designed so that the bank (i.e. the collection of all bank accounts) satisfies the following properties for any execution α.
• (Property P1) The total number of dollars deposited into the bank by an operation is O(h(up) +ċ(up)) during its update phase up, and O(h(cp) + rebal(viol(cp)) ·ċ(cp)) during its cleanup phase cp.
• (Property P2) Every failed attempt by an operation in its update phase up (or cleanup phase cp) withdraws one dollar from one of its own accounts.
• (Property P3) All bank accounts have non-negative balance.
Assuming these properties of the bank hold, it follows that the total number of failed attempts made in an execution α is bounded by the total money deposited into the bank. Thus, We note that a failed freezing CAS does not imply a failed SCX, as a helping process may have performed the freezing CAS on behalf of another process. The following definition is useful for characterizing when an SCX fails. Definition 6.18. Consider an invocation S of SCX that creates an SCX-record U . A freezing iteration of S on a node r is the iteration for r of the for-each loop on lines 24-35 of Help(U ). A freezing iteration fails if a successful abort step is performed during the freezing iteration, otherwise the freezing iteration is successful.
By definition, a SCX fails if and only if it performs a failed freezing iteration. It was shown that every unsuccessful invocation of LLX and SCX can blame some invocation of SCX for its failure [3]. We use the notion of blaming to help decide the bank account responsible to pay for a failed attempt caused by an unsuccessful LLX or SCX. Definition 6.19. Let I be an invocation of LLX(r) that returns Fail or Finalized. Let the failure step of I be the step when I reads r.info on line 9 if it exists, otherwise it is the step I reads r.info on line 4. Let U be the SCX-record pointed to by r.info when I performs its failure step. We say that I blames the invocation of SCX that created U . Definition 6.20. Consider an invocation I of SCX(V, R, f ld, new) that returns False. Suppose its freezing iteration for a node r ∈ V fails. Let the failure step of I be the first successful freezing CAS on r since the successful LLX(r) linked to I. Let U be the SCX-record pointed to by r.info immediately after the failure step of I, and let S be the invocation of SCX that created U . We say that I blames S for r.
The failure step will be the step in which a dollar is withdrawn from a bank account to pay for a failed attempt. Note that each unsuccessful LLX and SCX has exactly one failure step. The failure step s of an unsuccessful SCX I may occur before the SCX is invoked, although it will occur in the same attempt after the LLX(r) linked to I. If s is the freezing CAS on a node r, then by definition I fails its freezing iteration on r, and but was successful on all prior freezing iterations.
When referring to either an update or cleanup phase, we use the variable xp to avoid repeating similar definitions. For an attempt A of an update or cleanup phase xp, we define #llx(A) to be the number of LLX performed by xp during A. Likewise, we define #frz (A) to be the number of freezing iterations performed by xp during A. We define #llx(xp) = max A∈xp #llx(A) and #frz (xp) = max A∈xp #frz (A) . For update phases up, it can be verified by inspection that #frz (up) = #llx(up) ≤ 2 for Insert operations, and #frz (up) = #llx(up) ≤ 4 for Delete operations. For cleanup phases cp, #frz (cp) ≤ #llx(cp) ≤ 7.
We define LLXNode i (xp, A) to be the ith node on which xp performs an LLX in attempt A. Finally, consider an invocation S of SCX(V, R, f ld, new) by xp in attempt A. Let freezeNode i (xp, A) be the ith node in the sequence V enumerated in the order they are frozen.
For each node x in the chromatic tree at some point in the execution, and for each update or cleanup phase xp, we define the accounts B(xp), B llx (xp, x) and B scx (xp, x), in addition to the auxiliary bank accounts L i (xp) (for 1 ≤ i ≤ #llx(xp)) and F i (xp) (for 1 ≤ i ≤ #frz (xp)). For each bank account X(xp) (or X(xp, x)), where X refers to one of the previously defined types of bank accounts, we define X(xp, C) (or X(xp, x, C)) to be the number of dollars in X(xp) in a configuration C. A bank account X(xp) is active if xp is active. Each bank account is initially empty.
The auxiliary bank accounts will serve two purposes. First, they will pay for any failed attempts due to steps that occur prior to the start of a phase. Second, they will pay for failed attempts due to recent changes in the structure of the chromatic tree. Whenever the auxiliary accounts are empty, the B llx and B scx accounts will pay for failures due to failed LLXs and failed SCXs respectively. The B(xp) account will be responsible for transferring dollars into the B llx (xp, x) and B scx (xp, x) accounts whenever some update or cleanup phase xp ′ performs a successful freezing CAS on x which causes a failed attempt by xp that cannot be paid for by xp's auxiliary accounts.
Each cleanup phase cp will maintain additional S(cp, x) accounts for each node x in the chromatic tree.
Definition 6.21. An invocation I of TryRebalance(ggp, gp, p, v) starting from configuration C is called stale if one of v, p, gp, or ggp is not in the chromatic tree in C. If x is the first node in the sequence ggp, gp, p, v that is not in the chromatic tree in C, then the stale invocation I blames the node x.
The S(cp, x) accounts will pay for failed attempts resulting from stale invocations of TryRebalance that blame a node x. Finally, cp will maintain a B nil (cp) account that will pay for all failed TryRebalance due to failed Nil checks by cp.
We next give a summary of all the bank account rules. Note that when referring to an update CAS or commit step s for an update or cleanup phase xp, s may be performed by any process on behalf of the SCX invoked by xp. The deposit and withdraw rules for an update phase up are summarized in Figures 9 and 10 respectively. The deposit and withdraw rules for a cleanup phase cp are summarized in Figures 11 and 12 respectively. A final rule that transfers dollars between accounts by steps made by any operation is shown in Figure 13.

D1-S
Consider a successful update CAS ucas in configuration C for an update phase up. For all nodes x removed from the chromatic tree by ucas and for all cleanup phases cp ′ active during C, up deposits 1 dollar into S(cp ′ , x).

D1-LF
The start of an update phase up deposits 4 dollars into each of its own L i (up) accounts (for 1 ≤ i ≤ #llx(up)) and F i (up) accounts (for 1 ≤ i ≤ #frz (up)).

D2-LF
A successful update CAS for up deposits 4 dollars into each active L i and F i account owned by update phases, and 3 dollars into each active L i and F i account owned by cleanup phases.

D1-BUP
The start of an update phase up deposits 30h(up) + 120ċ(up) + 120 dollars into its own B   D1-S Consider a successful update CAS ucas in configuration C for a rebalancing transformation centered at viol(cp). For all nodes x removed from the chromatic tree by ucas and for all cleanup phases cp ′ active during C, cp deposits 1 dollar into S(cp ′ , x).

D1-LF
The start of an cleanup phase cp deposits 3 dollars into each of its own L i (cp) accounts (for 1 ≤ i ≤ #llx(cp)) and F i (cp) accounts (for 1 ≤ i ≤ #frz (cp)).

D2-LF
A successful update CAS for a rebalancing transformation centered at viol(cp) deposits 4 dollars into each active L i and F i account owned by update phases, and 3 dollars into each active L i and F i account owned by cleanup phases.

D1-BCP
The start of a cleanup phase cp deposits 78h (  From these deposit rules, property P1 of the bank can be verified. We formalize this in the following two lemmas.

W-STALE
A stale invocation of TryRebalance for a cleanup phase cp that blames a node x withdraws 1 dollar from S(cp, x).

W-LLX
The failure step of an LLX, I, by cp in attempt A during a non-stale invocation of TryRebalance on x = LLXNode i (cp, A) withdraws 1 dollar from L i (cp) if L i (cp) > 0. If L i (cp) = 0 and x is a downwards node for the SCX blamed by I, then cp withdraws 1 dollar from B llx (cp, x); otherwise it withdraws 1 dollar from B llx (cp, p), where p is the parent of x.
Finally, we can verify property P2 of the bank by the withdraw rules. Lemma 6.24. For an update phase or cleanup phase xp, xp withdraws 1 dollar from one of its own bank accounts for every failed attempt.

Proof.
A failed attempt of an update phase occurs after a failed LLX or SCX. The rules W-LLX and W-SCX pay for these respectively.
For a cleanup phase, all failed attempts due to stale invocations of TryRebalance are paid for by W-STALE. All non-stale invocations of TryRebalance fail due to a failed LLX, SCX, or Nil check. The rules W-LLX, W-SCX, and W-NIL pay for these respectively.
We have shown that Property P1 and P2 of the bank are satisfied. The remainder of the amortized analysis shows that the balance in each bank account is always non-negative. In Section 6.2.3, we prove properties of LLX and SCX required throughout the analysis. In Section 6.2.4 we define a set of nodes targets(up) for each update phase up, which is used by rule T1-B. In Section 6.2.5, we define a similar set of nodes targets(cp) for each cleanup phase cp, and prove properties about the S accounts. In Section 6.2.6, we prove properties of the L i and F i accounts. In Sections 6.2.7, 6.2.8, 6.2.9, and 6.2.10, we prove that the B llx , B scx , B nil , and B accounts, respectively, are non-negative.

Blaming Invocations of SCX
Recall that, unlike in [3], we consider an LLX that returns Finalized to be unsuccessful because it causes a failed attempt for an operation. In this section, we prove properties of blaming for an unsuccessful LLX that returns Fail or Finalized. These properties will be useful throughout the amortized analysis.
A step belongs to an SCX-record U if the step is performed in any invocation of Help(ptr), where ptr is a pointer to U . A step belongs to an instance SCX of S if the step belongs to the SCX-record created by S. The following properties of the implementation of LLX and SCX used in the chromatic tree were proven in [3], and are used throughout this section.
Observation 6.25. Let U be an SCX-record created by an instance S of SCX(V, R, f ld, new). Let r be a Datarecord. Let r be a Data-record.
1. The state of U is initially InProgress when U is first created. The state of U only changes from InProgress to Aborted after an abort step for U , or from InProgress to Committed after a commit step for U .
2. Every update to info field of r changes r .info to a value that has never previously appeared there.
3. Suppose a successful mark step mstep belonging to an SCX-record U on r occurs. Then r is frozen for U when mstep occurs, and forever after.
4. There cannot be both a frozen step and an abort step belonging to the same SCX-record.
5. Suppose a frozen step is performed for U . Then a commit step is performed for U before any invocation of Help(ptr) terminates, where ptr is a pointer to U .
6. If a frozen step belongs to U then, for each x ∈ U.V , there is a successful freezing CAS belonging to U on x that occurs before the first frozen step belonging to U .
7. Let the threatening section of S begin with the first freezing CAS for U , and end with the first abort or commit step for U . Every successful freezing CAS for U occurs during S's threatening section.
8. Let I be an invocation of LLX(r) that returns Fail, and suppose I blames S. Then a commit step or abort step is performed for S before I returns.
9. An invocation S of SCX(V, R, f ld, new) cannot be blamed for any r ∈ V by more than one invocation of SCX per process.
We extend Observation 6.25.8 for invocations of LLX that return Finalized instead of Fail.
Lemma 6.26. Let I be an invocation of LLX(r) that returns Finalized, and S be the invocation of SCX that is blamed by I. Then a commit step belonging to S is performed before I returns.
Proof. Since I returns Finalized, the if-statement on line 12 evaluates to True. So marked 1 = True, and either rinfo.state = Committed, or rinfo.state = InProgress and the invocation of Help(rinfo) returns True. Note that since marked 1 = True and marked nodes do not become unmarked, this implies that marked 2 = True. Therefore, I does not enter the if-block on line 7. Since I blames S, rinfo points to the SCX-record created by S. By Observation 6.25.1, if rinfo.state = Committed, then a commit step has already been performed for S. If rinfo.state = InProgress and the invocation of Help(rinfo) on line 12 returns True, then by Observation 6.25.5, a commit step has been performed for S. This is before I returns Finalized.
It was shown that each invocation of SCX can be blamed by at most two invocations of LLX that return Fail per process [3]. This result does not hold for LLXs that return Fail or Finalized. The following lemmas show that, under certain conditions, two failed invocations of LLX(r) (that either return Fail or Finalized) performed by the same process will blame different invocations of SCX. Lemma 6.27. Let S be an instance of SCX whose SCX-record U is in the Aborted state. If I is an instance of LLX(r) that is invoked after the first abort step belonging to S, then I does not blame S.
Proof. Suppose, for contradiction, that I blames S. We consider two cases, depending on what rinfo points to when I executes line 4 of LLX. First, suppose rinfo points to some SCX-record U ′ = U . Since I blames S, r.info points to U when I performs line 9. Note that r .info can only be updated by a successful freezing CAS on line 26 of Help. Additionally, U is in the Aborted state before the invocation of I. So by Observation 6.25.7, no successful freezing CAS for U occurs during I. This implies that r .info does not point to U at any point during I. This is a contradiction.
So suppose rinfo points to U when I executes line 4 of LLX. By Observation 6.25.1, the state of U remains Aborted after it is set to Aborted, and so state = Aborted when I executes line 5. Therefore, the if-statement on line 7 evaluates to True for I. Since I fails, the check on line 9 must have failed, and so r .info was updated to point to an SCX-record U ′ = U sometime after I executed line 4. By definition, I blames the SCX that created U ′ . Since each instance of SCX creates only one SCX-record, I does not blame S. Lemma 6.28. Let S be an instance of SCX whose SCX-record U is in the Commited state. Let I be an instance of LLX(r) invoked after the first commit step belonging to S. If r is a node in the chromatic tree for all configurations during I, then I does not blame S.
Proof. Note that since U is committed before the start of I, by Observation 6.25.7, there is no freezing CAS on r belonging to S during I. This implies that if r .info does not already point to U when I executes line 4, then r .info will not be updated to point to U at any later point during I. Hence, I does not blame S. So suppose when line 4 is executed for I, r .info points to U . Therefore, state = Committed when line 5 is executed for I.
Note that if marked 1 is True when I executes line 3, then r is both marked and r .info points to a committed SCX-record when I executes line 4. Hence, by definition, r is not a node in the chromatic tree. Therefore, marked 1 is False when I executes line 3.
We argue that marked 2 = False when I executes line 6. Suppose, for contradiction, that marked 2 = True. This implies r is marked by a mark step mstep sometime after I executes line 3, but before I executes line 6. Note that mstep cannot belong to U since a commit step for U has already been performed. Hence, by Observation 6.25.3, when mstep occurs, r is frozen for some SCX-record U ′ = U , and r .info points to U ′ in all configurations after mstep. We argue that there exists a configuration in which U ′ .state = Committed after mstep but before the end of I. This implies that r is not a node in the chromatic tree in this configuration because r is marked and r .info points to a committed SCX-record. Note that I does not enter the if-block on line 7 since marked 2 = True. Additionally, I does not enter the if-block on line 12 since marked 1 = False. Since r .info points to U ′ in all configurations after mstep, r .info points to U ′ immediately before I executes line 15. From the code, a mark step for U ′ only occurs after a successful frozen step for U ′ . Therefore, by Observation 6.25.4, U ′ is not in the Aborted state when I reads the state of r .info on line 15. If U ′ .state = Committed at this point, then r is not a node in the chromatic tree. If U ′ .state = InProgress at this point, then I invokes Help(r .info), where r .info points to U ′ . By Observation 6.25.5, a commit step for U ′ is performed before the termination of H. Immediately after this commit step, r is marked and r .info points to a committed SCX-record, so r is not in the chromatic tree.
Therefore, consider the case when marked 2 = False. Recall that state = Committed when line 5 is executed for I, and so I enters the if-block on line 7. Since I is a failed invocation of LLX, it fails the check on line 9. Hence, r .info points to an SCX-record U ′′ = U when line 9 is executed. Since an invocation of SCX only creates one SCX-record, U ′ is not created by S. Thus, I does not blame S. Lemma 6.29. Consider two failed invocations of I ′ of LLX(r ′ ) and I of LLX(r) by an operation, where I ′ precedes I. Suppose r is in the chromatic tree in all configurations between the start of I ′ and the end of I. Then I ′ and I blame different invocations of SCX.
Proof. Suppose that I ′ blames an invocation S of SCX, and let U be the SCX-record created by S. By Lemma 6.26 and Observation 6.25.8, either a commit step or abort step belonging to S is performed before the completion of I ′ .
If an abort step is performed, then by Lemma 6.27, I does not blame S since I is invoked after the abort step. If a commit step is performed, then by Lemma 6.28, I does not blame S since I is invoked after the commit step. Lemma 6.30. Let I be a failed invocation of LLX(r) that blames an SCX S. If no successful update CAS (belonging to any SCX) is performed between the last successful freezing CAS f cas belonging to S and the end of I, then an abort step belonging to I is performed before the end of I.
Proof. By Observation 6.25.8 and Lemma 6.26, either a commit step or abort step belonging to S ′ occurs before the end of I. Suppose, for contradiction, that a commit step belonging to S is performed. Observation 6.25.6 implies a frozen step belonging to S does not occur before f cas. Thus, a successful freezing CAS does not occur before f cas. From the code, a successful update CAS belonging to S is performed before its commit step. Therefore, a successful update CAS is performed sometime between fcas and the end of I, a contradiction. Lemma 6.31. Consider three failed invocations of I ′′ , I ′ , and I of LLX(r) by an operation. Suppose that between the start of I ′′ and the failure step of I, r is in the chromatic tree and no successful update CAS occurs. Then I blames an SCX different from I ′ .
Proof. Let S ′′ , S ′ , and S be the invocations of SCX blamed by I ′′ , I ′ , and I, respectively. Let U ′ be the SCX-record created by I ′ . By Lemma 6.29, I ′′ and I ′ blame different SCX, and so S ′′ = S ′ . Since I ′′ and I ′ blame different SCX, a successful freezing CAS fcas ′ changes r.info to point to U ′ sometime after the failure step of I ′′ . Thus, no successful update CAS occurs between fcas ′ and the end of I ′ . By Lemma 6.30, an abort step belonging to U ′ is performed before the end of I ′ . Since I is invoked after the abort step belonging to S ′ , by Lemma 6.27, I does not blame S ′ . Therefore, S = S ′ .
In the case that two consecutive invocations I ′ and I of LLX(r) blame different invocations of SCX, we can prove that the freezing CASs for the SCX blamed by I occur sometime between the start of I ′ and the failure step of I. Lemma 6.32. Consider two failed invocations of I ′ and I of LLX(r) by an operation, where I ′ precedes I. Let S ′ and S be the invocations of SCX blamed by I ′ and I, respectively, where S = S ′ . Suppose r is in the chromatic tree in all configurations between the start of I ′ and the failure step of I. Then there is no successful freezing CAS belonging to S occurs before the start of I ′ .
Proof. Let U ′ and U be the SCX-records created by S ′ and S, respectively. Since I ′ blames S ′ , the failure step of I ′ reads that r.info points to U ′ . Thus, there exists a successful freezing CAS fcas ′ for S ′ that points r.info to U ′ . Likewise, there is a successful freezing CAS fcas for S that points r.info to U . Suppose fcas ′ occurs after fcas. Then r.info points to U sometime before the failure step of I ′ . Observation 6.25.2 implies that r.info will not point back to U , and so I does not blame S. Therefore, fcas ′ occurs before fcas.
It remains to show that no successful freezing CAS for S occurs before the start of I ′ . For contradiction, suppose there is a successful freezing CAS for S that occurs before the start of I ′ . Then all LLXs linked to S have succeeded before the start of I ′ . Let J be the successful invocation of LLX(r) linked to S. First, suppose J reads that rinfo points to an SCX-record U ′′ = U ′ on line 4. Note that fcas ′ occurs sometime after this point since I ′ reads rinfo points to U ′ sometime during its execution. Then r .info no longer points to U ′′ when fcas occurs. This implies that fcas fails, which contradicts the fact that fcas is a successful freezing CAS.
So suppose J reads that rinfo points to U ′ on line 4. Since J is successful, when J executes line 7, either U ′ .state = Aborted, or U ′ .state = Committed and marked 2 = False. If U ′ .state = Aborted, then by Lemma 6.27, no LLX invoked after J can blame S ′ . In particular, this contradicts the fact that I ′ blames S ′ . If U ′ .state = Committed, then by Lemma 6.28, I ′ does not blame S ′ . Therefore, no successful freezing CAS for S occurs before the beginning of I ′ .
A similar lemma can be proven for two invocations of SCX that fail a freezing iteration on the same node r, but blame different invocations of SCX. Lemma 6.33. Consider two failed invocations of I ′ and I of SCX(V, R, f ld, new) by an operation, where I ′ precedes I. Suppose both I ′ and I fail a freezing iteration on the same node r, and let S be the invocation of SCX blamed by I. Let L ′ be the first invocation of LLX linked to I ′ . Then no successful freezing CAS belonging to S occurs before the beginning of L ′ .
Proof. By Observation 6.25.9, S can only be blamed for r by at most one SCX per process. So I ′ blames some invocation S ′ = S of SCX for r.
Suppose, for contradiction, there is a successful freezing CAS belonging to S that occurs before the start of L ′ . Then all LLXs linked to S must have succeeded before the start of L ′ . Let J be the LLX(r) linked to S. Let fcas ′ be the successful freezing CAS on r belonging to S ′ . Since the LLX(r) linked to I ′ succeeded (otherwise I ′ does not perform a freezing iteration on r), fcas ′ occurs after the LLX(r) linked to I ′ , but before the failed freezing iteration on r belonging I ′ . This implies no freezing CASs on r belonging to S will succeed, since r.info no longer points to the same SCX-record as seen by J. Since r.info never points to the SCX-record created by S, I does not blame S, which is a contradiction.

Target Nodes of an Update Phase
In this section, we define a set of nodes targets(up, C) for every update phase up and configuration C in an execution. This set of nodes is used when proving properties of the bank accounts. We prove that the nodes in targets(up, C), except for the node targetRoot(up, C), are the nodes on which up performs LLXs in a successful update attempt in a solo execution from C. To formally define targets(up), we introduce the following definitions. Definition 6.34. Let the extended tree T * of a chromatic tree T be a tree containing all nodes in T , in addition to new nodes so that: • the subtree rooted at each leaf of T is a complete tree with depth 2, • the entry node of T has 4 ancestors, • the parent of entry has a new right child that is the root of a complete tree of depth 2, and • the grandparent of entry has a new right child which is a leaf.
The nodes in T * that are not in T are called phantom nodes. Let the phantomRoot be the topmost ancestor of entry in T * . The extended tree is illustrated in Figure 14.  For an update phase or cleanup phase xp of an Insert(k) or Delete(k) operation, let xp's search path be the search path for the key k. For an update phase up, let focalNode(up, C) be the unique leaf on up's search path in C, which is the node labeled l in Figure 15. For each update phase up and configuration C, we define a set of nodes in the chromatic tree denoted by targets(up, C). Proof. We prove the case for when xp is an update phase. The case for when xp is a cleanup phase follows similarly.
Suppose, for contradiction, that m is marked when xp executes line 4 of BacktrackingSearch. By Lemma 6.9, there exists a configuration C before the next pop by xp where m is not a node in the chromatic tree. Only update CASs can remove a node from the chromatic tree. Thus, an update CAS has removed m from the chromatic tree since the point when m was popped by xp. This contradicts the assumption that no update CAS occurs during A. Lemma 6.38. Consider an attempt A of an update or cleanup phase xp for an Insert(k) or Delete(k) operation where no successful update CAS (by any operation) occurs during A. Then the last node popped by xp during backtracking in A (or entry if A is the first attempt of xp) is in the chromatic tree and on the search path for k for all configurations during A.
Proof. We prove the case for when xp is an update phase. The case for when xp is a cleanup phase follows similarly.
Let m be the last node popped by xp. If m = entry, then m is always in the chromatic tree and is on the search path for every key in the tree. So suppose m = entry. From the code on lines 4-6 of BacktrackingSearch, if m is marked when xp executes line 4 with l = m, then xp pops another node on line 6. This contradicts the fact that m is the last node popped by xp during backtracking in A. So m is unmarked when xp executes line 4. Since marked nodes do not become unmarked, m was unmarked in the configuration C immediately before it is popped. By Lemma 5.19, m is on the search path for k in C, and therefore also in the chromatic tree in C. Since no update CASs occur during A, the structure of the chromatic tree does not change during A. It follows that m is in the chromatic tree and on the search path for k for all configurations during A. Lemma 6.39. Let A ′ be an unsuccessful attempt of an update phase up, and let A be an attempt of up following A ′ . Suppose no successful update CAS occurs between the start of A ′ and the end of A. Let gp ′ , p ′ , and l ′ be the last three nodes on the up's search path at the start of A ′ . If TryInsert(p ′ , l ′ ) or TryDelete(gp ′ , p ′ , l ′ ) is invoked in A ′ , then up invokes TryInsert(p ′ , l ′ ) or TryDelete(gp ′ , p ′ , l ′ ) in A.
Proof. Note that since no update CAS occurs throughout A ′ and A, gp ′ , p ′ , and l ′ are the last three nodes on up's search path for all configurations between the start of A ′ and the end of A. Suppose up invokes Try-Delete(gp ′ , p ′ , l ′ ) in A ′ . The top node on up's stack at the end of A ′ is gp ′ . Since gp ′ is a node in the chromatic tree, by Lemma 6.37, up stops backtracking at gp ′ . Since gp ′ , p ′ , and l ′ are the last three nodes on the search path for k, it follows that up will invoke TryDelete(gp ′ , p ′ , l ′ ) in A. The case for when up invokes TryInsert(p ′ , l ′ ) follows similarly. Lemma 6.40. Let A ′ be an unsuccessful attempt of an update phase up, and let A be an attempt of up following A ′ . Let gp ′ , p ′ , and l ′ be the last three nodes on up's search path at the start of A ′ . If no successful update CAS occurs between the start of A ′ and the end of A, then up invokes TryInsert(p ′ , l ′ ) or TryDelete(gp ′ , p ′ , l ′ ) in A.
Proof. Suppose up is the update phase of an Insert(k) operation. In the instance of BacktrackingSearch by up in A, up begins by backtracking to an unmarked node m. By Lemma 6.38, m is in the chromatic tree and on the search path for k for all configurations during A. By the check on line 7, only internal nodes are pushed onto the stack, so m is not a leaf and is a proper ancestor of l ′ throughout A. Since no update CASs occur throughout A, any nodes that up visits when looking for a leaf during A by following pointers from m are also in the chromatic tree. Therefore, by Lemma 5.8,each node that up visits is on the search path for k. Since p ′ and l ′ are on the last two nodes on the search path for k starting from m for any configuration during A, up's invocation of BacktrackingSearch returns the nodes p ′ and l ′ . It follows that up will invoke TryInsert(p ′ , l ′ ) in A.
So suppose up is the update phase of a Delete(k) operation. At the start of up in A ′ , up begins by backtracking to an unmarked node. Let m ′ be the last node popped by up during backtracking (or m ′ = entry if A ′ is the first attempt of up). By Lemma 6.38, m ′ is in the chromatic tree and on the search path for k for all configurations in A ′ . By the check on line 7, only internal nodes are pushed onto the stack, and so m ′ is not a leaf. It follows that m ′ is a proper ancestor of l. We consider the following two cases, depending on the node m ′ .
Suppose m ′ = p ′ . So m ′ is a proper ancestor of p ′ . Then by Lemma 5.8, the nodes gp ′ , p ′ , and l ′ are on the search path for up starting from m ′ , and so up invokes TryDelete(gp ′ , p ′ , l ′ ) in A ′ . By Lemma 6.39, up invokes Then up only performs a single pointer traversal when looking for a leaf before visiting l. After visiting l ′ , up performs Pop (on line 10 of BacktrackingSearch) on its stack that returns p ′ , and Top (on line 11 of BacktrackingSearch), returning a node gp ′′ . Then up invokes TryDelete(gp ′′ , p ′ , l ′ ) in A ′ .
If gp ′′ = gp ′ , then by Lemma 6.39, up invokes TryDelete(gp ′ , p ′ , l ′ ) in A. So suppose gp ′′ = gp ′ , and up invokes TryDelete(gp ′′ , p ′ , l ′ ) in A ′ . This invocation of TryDelete is unsuccessful, otherwise a successful update CAS will occur during its successful SCX. In the attempt A, up backtracks starting from gp ′′ to a node m. Note that m = p ′ because p ′ was popped from the stack at the end of A ′ . By Lemma 6.38, m is in the chromatic tree and on the search path for k for all configurations during A. Then m is a proper ancestor of p ′ . Therefore, by Lemma 5.8, the nodes gp ′ , p ′ , and l ′ are on the search path for up starting from m. Therefore, up invokes TryDelete(gp ′ , p ′ , l ′ ) in A.
In the following lemma, we show that if no update CASs occur, then up will eventually perform LLXs on nodes in targets(up, C) − {targetRoot(up, C)}. Lemma 6.41. Let A ′ be an unsuccessful attempt of an update phase up, and let A be an attempt of up following A ′ . If no successful update CAS occurs between the start of A ′ and the end of A, then for all 1 ≤ i ≤ #llx(A) and for any configuration C between the beginning and end of A, LLXN ode i (up, A) ∈ targets(up, C) − {targetRoot(up, C)}.
Proof. No update CAS occurs between the start of A ′ and the end of A, so the structure of the chromatic tree does not change between start of A ′ and the end of A. Thus targets(up) does not change between the start of a A ′ and the end of A. It is therefore sufficient to show that for any configuration C during A, up only performs LLXs on nodes in targets(up, C) during A.
Suppose up is for a Delete(k) operation. By Lemma 6.40,up invokes TryDelete(gp,p,l) in A, where gp, p, and l are the last three nodes on the search path for k in C. From the code of TryDelete, if no update CAS is performed during this instance, up will only perform LLXs on gp, p, l, and the sibling of l. By definition, these nodes are in targets(up, C).
Suppose up is for a Insert(k) operation. By Lemma 6.40,up invokes TryInsert(p,l) in A, where p, and l are the last two nodes on the search path for k in C. From the code of TryInsert, up will only perform LLXs on p and l. By definition, these nodes are in targets(up, C) − {targetRoot(up, C)}.

Target Nodes of a Cleanup Phase
In this section, for each cleanup phase cp, we define a set of nodes targets(cp) with properties similar to those of targets(up). The goal is to prove a lemma similar to Lemma 6.41, except for targets(cp). The definition of targets(cp) is more complicated than targets(up). This is because the violation cp encounters may be different in different cleanup attempts, even in the case where the structure of the chromatic tree does not change during the attempts. Additionally, concurrent operations may move violations onto cp's search path, causing it to perform cleanup attempts it would otherwise not perform.
To define targets(cp), we require a number of other definitions.
Definition 6.42. For any node v in the chromatic tree in configuration C, let rebalSet(v, C) be the set of nodes in the extended tree T * including the following 13 nodes: • v and its four closest ancestors (labeled p, gp, ggp, and gggp), Notice that any rebalancing transformation centered at v involves a subset of the nodes contained in rebalSet(v). The tree T * is defined so that for any node v in T in configuration C, all 13 nodes in rebalSet(v, C) exist in T * . Recall that location(P, C) for a process P in its cleanup phase is defined as the node pointed to by P 's local variable l in BacktrackingCleanup in configuration C. Definition 6.43. For each cleanup phase cp by a process P and configuration C, we define an auxiliary variable currentV iol(cp) that is initially Nil at the start of cp and updated by the following rules: • Rule CV1: A step s changes currentV iol(cp) from Nil to a node v if 1. cp visits v during s, 2. v is a node in the chromatic tree containing a violation, and 3. the 3 topmost nodes on P 's stack are v's three closest ancestors.
• Rule CV2: An update CAS changes currentV iol(cp) from a node v = Nil to Nil if v or one of its three closest ancestors are removed from the chromatic tree by the update CAS.
Intuitively, when cp is performing a rebalancing transformation centered at a node v in the chromatic tree in a configuration C, currentV iol(cp, C) = v. The definition of currentV iol(cp) gives conditions where cp will encounter the same violation v between consecutive cleanup attempts, provided no update CAS occurs during these attempts. Lemma 6.44. Consider a process P in cleanup phase cp in configuration C. If currentV iol(cp, C) = v = Nil, then 1. v is in the chromatic tree in C, 2. location(P, C) ∈ {v, p, gp, ggp}, where p, gp, and ggp are the three closest ancestors of v, 3. there is a violation at v on P 's search path, 4. there is no violation at p, gp, or ggp, and 5. if C is immediately after a step that updates P 's local variable l, then the nodes in the sequence p, gp, ggp that are proper ancestors of location(P, C) are the topmost nodes on P 's stack in C.
Proof. We prove by induction on the sequence of steps in the execution. Consider a step s in the execution, and let C − and C be the configurations immediately before and after s. In the base case, suppose currentV iol(cp, C − ) = Nil and currentV iol(cp, C) = v. Then by rule CV1 of Definition 6.43, location(P, C) = v, where v is a node in the chromatic tree containing a violation. So conditions 1, 2, and 3 of the lemma are satisfied. Additionally, the topmost nodes on P 's stack are p, gp, and ggp. Thus, condition 5 is satisfied. Finally, by Lemma 5.11, nodes on a process's stack during its cleanup phase do not contain violations, so condition 4 is satisfied. So suppose the lemma holds in C − where currentV iol(cp, C − ) = v, and we show the lemma holds in C. By rule CV2 of Definition 6.43, s is not an update CAS that removes one of v, p, gp, or ggp from the chromatic tree, otherwise currentV iol(cp, C) = Nil. By Lemma 5.10, violations are only added to a node when it is first added to the chromatic tree. Therefore, since conditions 1, 3 and 4 are satisfied in C − , they are satisfied in C. Note that if s does not update the local variable l, then since conditions 2 and 5 are satisfied in C − , they will be satisfied in C. In this case, currentV iol(P, C) = v. So suppose s updates P 's local variable l. We first argue that s is not a step that updates P 's local variable l on line 4 or 8.
• Suppose step s updates the local variable l to entry on line 4. Then cp is the first cleanup attempt of P 's current operation. So l is undefined before s, and s is the first step that updates P 's local variable l in cp. Thus, location(P, C − ) = Nil.
• Suppose step s updates the local variable l by the Pop on line 8. The last time P executed line 6, P read that the node pointed to by l was marked. Thus location(P, C − ) is a marked node in C − . By Lemma 6.9, location(P, C − ) is not a node in the chromatic tree in C − . Since the nodes v, p, gp, and ggp are in the chromatic tree, location(P, C − ) / ∈ {v, p, gp, ggp}. Thus, currentV iol(P, C − ) = Nil.
The only remaining updates to the local variable l are on lines 5 and 18 of BacktrackingCleanup.
• Suppose step s updates the local variable l by the Pop on line 5. Then this is the first update to l in P 's current attempt. The previous attempt by P ended with an invocation I of TryRebalance. Since I is called when a violation is found at the node pointed to by l, and the only node that contains a violation among the nodes {v, p, gp, ggp} is v, l points to v when I is invoked. Note that P 's local variable l is not updated between the start of I and C − , and so location(P, C − ) = v. Then by condition 5, the last nodes visited by P in C − were the nodes {v, p, gp, ggp}. Thus, in the last three iterations of the while-loop on line 9 prior to I, P 's local variable l pointed to each of p, gp, and ggp. These nodes are pushed onto P 's stack on line 17. Then when P finds a violation at v on line 10 in the iteration I is invoked, the top nodes on P 's stack are p, gp, and ggp. Thus, p is the node popped by P on line 11, gp is the node popped by P on line 12, ggp is the top node on P 's stack read on line 13. So ggp is the topmost node on P 's local stack in C. Since s updates the local variable l to the top node on P 's stack, location(P, C) = ggp. There are no proper ancestors of ggp in p, gp, ggp , so condition 5 is vacuously true in C. So currentV iol(P, C) = v. Definition 6.45. Suppose that P is in its cleanup phase in configuration C. Consider the solo execution by P from C until it finishes its cleanup phase. If its local variable l does not point to any node in the chromatic tree in C during this solo execution, then define nextNode(P, C) = Nil. Otherwise, define nextNode(P, C) to be the node in the chromatic tree in C that is first pointed to by l during this execution.
Note that by definition, if nextN ode(P, C) = Nil, then nextN ode(P, C) is a node in the chromatic tree in C. We next prove properties of nextNode(P, C). Lemma 6.46. Suppose nextNode(P, C) = Nil and P performs backtracking at some point during its solo execution starting from C prior to visiting nextNode(P, C). Then in configuration C, nextNode(P, C) is a node on P 's stack.
Proof. By the definition of nextN ode, P does not visit any nodes that are in the chromatic tree in C before the point in which P first begins backtracking. By definition, backtracking only ends when P visits an unmarked node, which by Observation 5.1.3 and Lemma 5.2, is in the chromatic tree. Thus, P is backtracking when it first visits nextN ode(P, C) in its solo execution starting from C. During backtracking, P only visits nodes on its stack. Hence, P is a node on P 's stack. Lemma 6.47. If nextNode(P, C) = Nil, then in configuration C, it is either a node on P 's stack, or it is the first node on P 's search path starting from location(P, C) that is in the chromatic tree.
Proof. Suppose P performs backtracking at some point during its solo execution starting from C but before the step in which P first visits nextNode(P, C). By Lemma 6.46, nextNode(P, C) is a node on P 's stack in C.
So suppose P does not perform backtracking at some point during its solo execution starting from C but before the step in which P first visits nextNode(P, C). Note that P is not in an invocation of TryRebalance throughout its solo execution, since P does not visit nodes in TryRebalance and P begins backtracking immediately after TryRebalance. So P is looking for a violation throughout its solo execution. From the code, P only updates its local variable l when it executes line 18 of BacktrackingCleanup. Each node P visits when looking for a violation during its solo execution starting from C is on its search path from location(P, C). Thus, nextN ode(P, C), the first node that P visits in its solo execution starting from C that is in the chromatic tree in C, is on P 's search path from location(P, C) Lemma 6.48. Let P be a process in a configuration C such that nextNode(P, C) = Nil. Then in any execution starting from C, P only visits nodes that are no longer in the chromatic tree in C before visiting nextN ode(P, C).
Proof. Consider the sequence of nodes x 1 , . . . , x k visited by P in its solo execution starting from C, where x 1 = location(P, C) and x k = nextNode(P, C). By definition, x 1 , . . . , x k−1 are not nodes in the chromatic tree, and so are marked. Since the fields of marked nodes are not changed, x 1 , . . . , x k have the same child pointers in all configurations C ′ reachable from C. Thus, x 1 , . . . , x k are the first nodes visited by P in any execution starting from C. Lemma 6.49. If nextNode(P, C) = Nil, then for any configuration C ′ after C but before the end of P 's current operation, nextNode(P, C ′ ) = Nil.
Proof. Consider the solo execution by P from C until it finishes its cleanup phase. We first prove P does not pop from its stack on line 5 or 8 of BacktrackingCleanup. Suppose, for contradiction, that P does perform such a pop. Since nextNode(P, C) = Nil, every node that P visits in this solo execution is not in the chromatic tree and also marked. Then when P first executes line 6 following C, it reads that the node pointed to by l is marked. This implies that P does not exit the while-loop on line 6. Then P will eventually pop entry from the stack on line 8. When P visits entry, this contradicts the fact that entry is always a node in the chromatic tree.
Note that P does not invoke TryRebalance in its solo execution from C. Otherwise, a pop on line 5 will be executed after this instance of TryRebalance is completed. Therefore, the check on line 10 never finds a violation in P 's solo run from C. Thus, P will eventually visit a leaf node and exit its current operation. Let x 1 , ..., x k be the nodes visited by P , where x k is the leaf node. The nodes x 1 , ..., x k are not in the chromatic tree and hence they are marked. Since the fields of marked nodes are not changed, x 1 , ..., x k have the same child pointers in all configurations C ′ reachable from C. Therefore, P will only visit the nodes in {x 1 , ..., x k } in a solo run execution starting from C ′ . Thus, nextNode(P, C ′ ) = Nil. Definition 6.50. Consider a process P in its cleanup phase cp in configuration C. Let focalNode(cp, C) be a node in the chromatic tree in C or Nil according to the following cases.
It follows by definition that focalNode(cp, C) is a node in the chromatic tree in C, provided focalNode(cp, C) = Nil. The following lemmas prove properties of focalNode(cp, C). Lemma 6.51. For any process P in its cleanup phase cp and configuration C, if location(P, C) is in the chromatic tree, then location(P, C) is an ancestor of focalNode(cp, C) and the distance between location(P, C) and focalNode(cp, C) is at most 3.
Proof. If focalNode(cp, C) = location(P, C), the lemma holds trivially. If focalNode(cp, C) = currentV iol(cp, C), then by Lemma 6.44, location(P, C) is an ancestor of focalNode(cp, C) and the distance between location(P, C) and focalNode(cp, C) is at most 3. Lemma 6.52. For any process P in its cleanup phase cp and configuration C, if location(P, C) is not in the chromatic tree, then f ocalN ode(cp, C) = nextN ode(P, C).
Proof. By Lemma 6.44, if location(P, C) is not in the chromatic tree, then currentV iol(cp, C) = Nil. Therefore, by the definition of the focal node, f ocalN ode(cp, C) = nextN ode(P, C). Lemma 6.53. For any process P in its cleanup phase cp and configuration C, nextN ode(P, C) = location(P, C) if and only if focalNode(cp, C) = nextN ode(P, C).
Suppose focalNode(cp, C) = nextN ode(P, C). By Definition 6.50.3, location(P, C) is not in the chromatic tree in C. Since P 's local variable l does not point to a node in the chromatic tree in C, nextN ode(P, C) = location(P, C). Proof. Let P be the process in cleanup phase cp. We prove the lemma by considering each case in Definition 6.50.
Suppose focalNode(cp, C) = currentV iol(cp, C). Then P has visited v in some step before C. By Lemma 5.17, currentV iol(cp, C) is on P 's search path in C.
Suppose focalNode(cp, C) = location(P, C). By Corollary 5.17, there is a configuration before C in which location(P, C) is on P 's search path. Therefore, by Lemma 5.3, location(P, C) is on P 's search path in C.
Suppose focalNode(cp, C) = nextN ode(P, C). By definition, nextN ode(P, C) is a node in the chromatic tree. If nextN ode(P, C) is on P 's stack, then by Lemma 5.18, nextN ode(P, C) is on P 's search path in C. If nextN ode(P, C) is not on P 's stack, then it is the first node in the chromatic tree that P will visit in a search starting from location(P, C). Let C ′ be the first configuration in which P visits nextN ode(P, C) in its solo execution starting from C. By Corollary 5.17 and Lemma 5.3, nextN ode(P, C) is on P 's search path in the configuration C ′ . Since the structure of the chromatic tree does not change from between C and C ′ , nextN ode(P, C) is on P 's search path in C. Definition 6.55. For a cleanup phase cp in configuration C, let targets(cp, C) = rebalSet(focalNode(cp, C), C).
Let targetRoot(cp, C) be the root node of the tree formed by nodes in targets(cp, C). The following lemma serves a similar role as Lemma 6.41. Lemma 6.56. Consider the invocation of TryRebalance(ggp, gp, p, v) during an attempt A of a cleanup phase cp. Let C be the configuration immediately after this invocation of TryRebalance. If currentV iol(cp, C) = v = Nil and no update CAS occurs between C and the end of A, then cp only performs LLXs on nodes in targets(cp, C) − {targetRoot(cp, C)}.
Proof. Since currentV iol(cp, C) = v, it follows by definition that focalNode(cp, C) = v and targets(cp, C) = rebalSet(v, C). Since no update CAS occurs between C and the end of A, by Definition 6.43, currentV iol(cp) does not change between C and the end of A. Thus, targets(cp) does not change between C and the end of A. By inspection of the code of TryRebalance, cp will only perform LLXs on nodes in targets(cp, C), no matter which rebalancing transformation is performed.
We next describe the conditions in which currentV iol(cp) is equal to some node v which contains a violation. Recall that an invocation I of TryRebalance (ggp, gp, p, v) is called stale if one of v, p, gp, and ggp is not in the chromatic tree. A stale invocation of TryRebalance will fail since an LLX on a node not in the chromatic tree returns Finalized. A stale invocation of TryRebalance(ggp, gp, p, v) blames a node x if x is the first node in the sequence ggp, gp, p, v that is not in the chromatic tree in C. Our analysis pays for all failed attempts caused by stale invocations of TryRebalance that blame a node x using the auxiliary bank accounts S(cp, x). Each S(cp, x) account is initially empty. It is activated in the first configuration in which cp is active and x is in the chromatic tree. Once activated, it is updated as follows: • D1-S: Consider a successful update CAS ucas in configuration C for an Insert or Delete transformation by xp, or for a rebalancing transformation centered at viol(xp). For all nodes x removed from the chromatic tree by ucas and for all cleanup phases cp ′ active during C, xp deposits 1 dollar into S(cp ′ , x).
• W-STALE: A stale invocation of TryRebalance for a cleanup phase cp that blames a node x withdraws 1 dollar from S(cp, x).
Lemma 6.57. Consider a non-stale invocation I of TryRebalance(ggp, gp, p, v) by a process in a cleanup phase cp. Then currentV iol(cp, C) = v, where C is the configuration immediately after I is invoked.
Proof. From the code, cp invokes TryRebalance(ggp, gp, p, v) if cp's local variable l points to v ′ . Consider the step s that last updated l to point to v. Let C ′ be the step immediately after this step. From the code, if cp invokes TryRebalance(ggp, gp, p, v), then the topmost nodes on P 's stack are p, gp, and ggp in C ′ . Therefore, by rule CV1 of Definition 6.43, currentV iol(cp, C ′ ) = v. Since I is non-stale, ggp, gp, p, and v are still in the chromatic tree immediately before the start of I. Thus, no update CAS has removed one of ggp, gp, p or v. Since no step applies rule CV2 of Definition 6.43 between C ′ and C, currentV iol(cp, C) = v.
Lemma 6.58. A node x is blamed by at most one invocation of TryRebalance for each cleanup phase cp.
Proof. Let I be a stale invocation of TryRebalance(ggp, gp, p, v) that blames a node x, where x ∈ {ggp, gp, p, v}. From the code, gp, p, and v are not on cp's stack at the start of I. After I fails, cp begins a new cleanup attempt. Let A be any attempt after I. Let m the last node popped during backtracking during A. By the check on line 6 of BacktrackingCleanup, m is unmarked and therefore in the chromatic tree. So m = x. Since x is not in the chromatic tree when I was invoked and is never added back to the chromatic tree, x is not reachable from m. Since cp's search during A does not visit the node x and is not on cp's stack, it follows from the code of BacktrackingCleanup that cp does not invoke TryRebalance with x as a parameter during A. Thus, cp does not blame x for a stale invocation of TryRebalance in any attempt that begins after the end of I. Proof. Suppose for contradiction, that there exists a cleanup phase cp, node x, and configuration C such that S(cp, x, C) < 0. Let C − be the configuration immediately before C. Then in the step immediately prior to C, cp performs a stale invocation I of TryRebalance that blames x and S(cp, x, C − ) = 0. By definition, x is not in the chromatic tree in C − . Consider the configuration C ′ immediately before x was removed from the chromatic tree. Node x must have been reachable by cp in some configuration before C ′ for it to perform I with x as a parameter, and so cp was active during C ′ . Therefore, by rule D1-S, a dollar is deposited into S(cp, x) by the update or cleanup phase that removed x from the chromatic tree. Therefore, S(cp, x, C ′ ) > 0. Since S(cp, x, C − ) = 0, there exists a stale invocation I ′ = I of TryRebalance in some configuration between C ′ and C − that blames x and withdraws a dollar from S(cp, x) by W-STALE. This contradicts Lemma 6.58, which states that cp can only blame x for one stale invocation of TryRebalance.
Lemma 6.59 proves that all unsuccessful cleanup attempts caused by stale invocations of TryRebalance can be paid for by the S accounts. Failed attempts due to non-stale invocations of TryRebalance by cp are accounted for by cp's other accounts, as described in the following sections.

The L i and F i Accounts
In this section, we prove properties of the auxiliary bank accounts L i (xp) (for 1 ≤ i ≤ #llx(xp)) and F i (xp) (for 1 ≤ i ≤ #frz (xp)) for an update phase or cleanup phase xp. Intuitively, the L i (xp) accounts pay for the failed LLXs that occur within xp's first few attempts, or when successful update CASs have occurred sometime within xp's last few attempts. Likewise, the F i (xp) accounts pay for failed SCXs in these same cases. The remaining failed LLXs and SCXs are paid for by the B llx (xp) and B scx (xp) accounts, respectively.
By rule W-LLX, a dollar is withdrawn from an L i account as the result of a failure step of an LLX, provided the L i account is non-empty. Therefore, the L i accounts always have a non-negative balance. We next prove the properties of the L i accounts in the configurations that they are empty and a failure step of an LLX by occurs. Lemma 6.60. Suppose A is an attempt of a phase xp that fails an LLX which blames an SCX S. Let i be the number of LLXs performed by xp during A (so the ith LLX by xp is unsuccessful). Let C be the configuration immediately before the failure step of xp's unsuccessful LLX. If L i (xp, C) = 0, then there exists a previous attempt A ′ of xp such that By Lemma 6.56, the nodes in which cp performs its LLXs in attempts A ′′ , A ′ and A are in targets(cp), proving part 3. Since a dollar is deducted from L i (cp) in A ′′ , A ′ and A, A ′′ , A ′ and A fail an LLX on LLXNode i (cp, A), proving part 4. Note that since LLXNode i (cp, A) ∈ targets(cp, C), LLXNode i (cp, A) is in the chromatic tree between the start of A ′ and C. Hence, by Lemma 6.31, the failed LLXs on LLXNode i (cp, A) in A ′ and A blame different invocations of SCX, proving part 5. By Lemma 6.32, each successful freezing CAS belonging to S up to its successful freezing CAS on LLXNode i (cp, A) occurs sometime between the start of A ′ and C. This proves part 6.
By rule W-SCX, a dollar is withdrawn from an F i account as the result of a failure step of an SCX, provided the F i account is non-empty. We can prove a similar result to 6.60 for the bank account F i (up). Lemma 6.61. Suppose A is an attempt of a phase xp that fails a freezing iteration. Let i be the number of freezing performed by up during A (so the ith freezing iteration by up is unsuccessful). Let C be the configuration immediately before the failure step of this SCX. Let S be the SCX blamed by xp's unsuccessful SCX in A. If F i (xp, C) = 0, then there exists a previous attempt A ′ of xp such that 1. no successful update CAS occurs between the start of A ′ and C, 2. for every configuration C ′ between the starting configuration of A ′ and C, targets(xp, C) = targets(xp, C ′ ), 4. the ith freezing iteration performed by xp during A ′ is on freezeNode i (xp, A), which returns False, and 5. each successful freezing CAS belonging to S up to and including a successful freezing CAS on freezeNode i (xp, A) occurs between the start of A ′ and C.
Proof. The proof of parts 1, 2 and 3 follow from the proof of Lemma 6.60 by symmetry of the rules D1-LF and D2-LF to the L i and F i accounts, and by symmetry of the rule W-LLX to W-SCX. If xp is an update phase up, then part 4 follows from Lemma 6.40 because up performs the same successful LLXs in A ′ and A, and so up performs an invocation of SCX with the same parameters in A ′ and A. If xp is a cleanup phase cp, then part 4 follows from Lemma 6.56, because cp only performs freezing iterations on nodes it has previously performed LLXs on in the same attempt.
Since xp fails a freezing iteration on freezeNode i (xp, A), there is a successful freezing CAS belonging to S. Since all LLXs linked to xp's failed SCX in A ′ occur during A ′ , by Lemma 6.33, each successful freezing CAS belonging to S up to and including its successful freezing CAS on freezeNode i (xp, A) occurs between the start of A ′ and C. This proves part 5.

The B llx Accounts
In this section, we prove that the B llx accounts have a non-negative balance. The B llx accounts are responsible for paying for a failed attempt due to a failed LLX whenever the auxiliary accounts cannot pay for the failure. No rules deposit dollars directly into the B llx accounts. Instead, dollars are transferred into B llx accounts from B accounts by T1-B. We argue that the B llx accounts can always pay for a failed attempt when required by W-LLX. Proof. A dollar is only deducted from a B llx account owned by xp by rule W-LLX. Let s be the failure step of an LLX(x), I, from a configuration C − immediately before C that applies rule W-LLX. Suppose I is the ith LLX performed by xp in its current attempt A, so x = LLXNode i (xp, A). Let S be the SCX blamed by I, and let C ′ be the configuration immediately after x is frozen for S.
By rule W-LLX, L i (xp, C − ) = 0 if a dollar is withdrawn from B llx . By Lemma 6.60.4, there exists an attempt A ′ by xp before C in which xp fails an LLX on x. Note that by Lemma 6.60.1 and Lemma 6.60.2, for all configurations between the start of A ′ and C, no update CAS occurs and x is a node in targets(xp). Thus, x is in the chromatic tree during this interval.
We argue that the bank account from which xp withdraws 1 dollar by rule W-LLX during s is non-empty.
• Suppose x is a downwards node for S, so s withdraws 1 dollar from B llx (xp, x). By Lemma 6.60.6, C ′ occurs between the start of A ′ and C. By Lemma 6.60.3, x ∈ targets(up, C), and thus by Lemma 6.60.2, x ∈ targets(xp, C ′ ). Therefore, by T1-B, 1 dollar was transferred from B(xp) to B llx (xp, x) in configuration We argue that no step s ′ withdraws from B llx (xp, x) between C ′ and C − , and so B llx (xp, x, C) ≥ 0. Consider an unsuccessful LLX I ′ = I that blames an SCX S ′ . The failure step s ′ of I ′ withdraws from B llx (xp, x) if I ′ is performed on x and x is a downwards node for S ′ , or if I ′ is performed on a node y and y is a child of x and is a cross node for S ′ . Note that since C ′ is a step contained in A ′ , and there is a step of I ′ between C ′ and C − , it follows that I ′ starts after the start of A ′ . Since x is in the chromatic tree and no successful update CAS occurs between the start of A ′ and C − , the node on which I ′ is performed is in the chromatic tree between the start of I ′ and the end of I ′ .
Suppose s ′ is on the node x and x is a downwards node for S ′ . Since x is frozen for S in all configurations between C ′ and C, x.info only points to S immediately before s, and so I ′ blames S. Thus, by Lemma 6.31, I does not blame S, a contradiction.
Suppose s ′ is on the node y and y is a cross node for S ′ . Note that a cross node is only frozen for some SCX S ′ if its parent node is already frozen S ′ . Since x is frozen for S in all configurations between C ′ and C, y is a cross node for S. By Lemma 6.30, an abort step is performed for S before the end of I ′ . By Lemma 6.27, I does not blame S, a contradiction.
• Suppose x is a cross node for S, so s withdraws 1 dollar from B llx (xp, p), where p is the parent of s in C. Let C ′′ be the configuration in which p is frozen for S.
Notice that if x is a cross node for S, then by inspection of each chromatic tree transformation, the parent, p, of x is frozen for S before x. By Lemma 6.60.6, C ′′ occurs between the start of A ′ and C. By Lemma 6.60.3, x ∈ targets(xp, C) − {targetRoot(xp, C)}, and thus by Lemma 6.60.2, x ∈ targets(xp, C ′′ ) − {targetRoot(up, C)}. This implies p ∈ targets(up, C ′′ ). Therefore, by T1-B, 1 dollar was transferred from B(xp) to B llx (xp, p) in configuration C ′′ . So B llx (xp, p, C ′′ ) > 0.
We next argue that no step s ′ withdraws from B llx (xp, p) between C ′ and C − , and so B llx (xp, p, C) ≥ 0. Consider an unsuccessful LLX I ′ = I that blames an SCX S ′ . The failure step s ′ of I ′ withdraws from B llx (xp, p) if I ′ is performed on p and p is a downwards node for S ′ , or if I ′ is performed on a node x and x is a cross node for S ′ . Note that since C ′′ is a step contained in A ′ , and there is a step of I ′ between C ′′ and C − , it follows that I ′ starts after the start of A ′ . Since x is in the chromatic tree and no successful update CAS occurs between the start of A ′ and C − , the node on which I ′ is performed is in the chromatic tree between the start of I ′ and the end of I Suppose s ′ is on the node p and p is a downwards node for S ′ . Then since p is frozen for S ′ in all configurations between C ′′ and C, p.info only points to S during I ′ , and so I ′ blames S. Thus, by Lemma 6.31, I does not blame S, a contradiction.
Suppose s ′ is on the node x and x is a cross node for S ′ . Note that a cross node is only frozen for some SCX S ′ if its parent node is already frozen for S ′ . Since p is frozen for S in all configurations between C ′′ and C, x is a cross node for S. Thus, I ′ blames S ′ = S. By Lemma 6.30, an abort step is performed for S before the end of I ′ . By Lemma 6.27, I does not blame S, a contradiction.

The B scx Account
In this section, we prove that the B scx accounts have a non-negative balance. The B scx accounts are responsible for paying for the failed attempts caused by failed SCXs whenever the auxiliary accounts do not pay for the failures. No rules deposit dollars directly into B scx . Instead, dollars are transferred into B scx from B by T1-B.
Recall that when x is a cross node for an SCX S, then it is not the first node frozen for S. In this scenario, the following lemma applies. Lemma 6.63. Suppose an unsuccessful invocation I of SCX blames some SCX S for x, where x is a cross node for S. Then the only freezing iteration belonging to I is on x.
Proof. By inspection, except for the first node frozen for I, a node is only frozen for I if its parent is already frozen for I. Additionally, the first node frozen for an SCX is not a cross node. Therefore, when x is frozen for S, the parent p of x is already frozen for S.
Suppose, for contradiction, that I performs a freezing iteration on some node before its freezing iteration on x. Then I will perform a freezing iteration on p. Note that the LLX(p) linked to I occurs before p is frozen for S, since this LLX is successful. Therefore, if I performs a freezing iteration on p, the freezing iteration will be unsuccessful, and so I blames S for p instead of for x. Thus, the first freezing iteration belonging to I is performed on x. Since this freezing iteration is unsuccessful, no other freezing iterations belong to I.
We argue that the B scx accounts can always pay for a failed freezing iteration when required by W-SCX. Lemma 6.64. For all update phases and cleanup phases xp, all nodes x in the chromatic at some point in an execution, and all configurations C, B scx (xp, x, C) ≥ 0.
Proof. A dollar is only deducted from a B scx owned by xp according to rule W-SCX after the failure step of an SCX. Let s be the failure step of an unsuccessful SCX I from the configuration C − immediately before C. Suppose that in xp's attempt A containing I, the ith freezing iteration fails. Let x = freezeNode i (xp, A) and let S be the SCX blamed by I. By definition, s is the step in which x was frozen for S.
We argue that the bank account in which xp withdraws 1 dollar by rule W-SCX is non-empty. By rule W-SCX, F i (xp, C − ) = 0 whenever a dollar is withdrawn from a B scx account as a result of s.
Suppose x is a downwards node for S, so s withdraws 1 dollar from B scx (xp, x). By Lemma 6.61.3, x ∈ targets(xp, C) − {targetRoot(xp, C)}, and thus by Lemma 6.61.2,x ∈ targets(xp, So suppose x is a cross node for S, so s withdraws 1 dollar from B scx (xp, p), where p is the parent of s in C. Let C ′′ be the configuration immediately after p is frozen for S. By Lemma 6.61.4, there exists an attempt A ′ by xp before A in which xp fails a freezing iteration on x. By Lemma 6.61.5, C ′′ occurs between the start of A ′ and C. By Lemma 6.61.3, x ∈ targets(xp, C) − {targetRoot(xp, C)}, and thus by Lemma 6.61.2, x ∈ targets(xp, C ′′ ) − {targetRoot(xp, C ′′ )}. This implies p ∈ targets(xp, C ′′ ). Therefore, by T1-B, 1 dollar was transferred from B(xp) to B scx (xp, p) in configuration C ′′ . So B scx (xp, p, C ′′ ) > 0.
We argue that no step s ′ withdraws from B scx (xp, p) between C ′′ and C − , and so B scx (xp, p, C) ≥ 0. Suppose xp performs a failure step s ′ for some SCX I ′ between C ′′ and C that blames some SCX S ′ . By W-SCX, s ′ withdraws from B scx (xp, p) if s ′ is a freezing CAS on p and p is a downwards node for S ′ , or if s ′ is a freezing CAS on x and x is a cross node for S ′ .
Suppose s ′ is a freezing CAS on p and p is a downwards node for S ′ . Thus, by Definition 6.20, xp fails its freezing iteration on p belonging to I ′ . By Lemma 6.61.1 and Lemma 6.61.2, no successful update CAS occurs between the start of A ′ and C − , and the targets of xp do not change. Since the structure of the chromatic tree does not change, xp performs freezing iterations on the same nodes in I ′ and I. This implies that xp performs a successful freezing iteration on p belonging to I before its unsuccessful freezing iteration on x belonging to I. This contradicts Lemma 6.63.
Suppose s ′ is a freezing CAS on x and x is a cross node for S ′ . Thus, by Definition 6.20, xp fails its freezing iteration on x belonging to I ′ . Note that a cross node x is only frozen for S ′ if its parent node is already frozen for S ′ . Since p is frozen for S in all configurations between C ′′ and C − , S ′ = S. Thus, I ′ blames S for x. This contradicts Observation 6.25.9.

The B nil Account
The B nil (cp) accounts are responsible for paying for the failed attempts of a cleanup phase cp due to unsuccessful Nil checks in TryRebalance. The Nil checks are used by the TryRebalance routine to guarantee Nil pointers are not traversed. It was shown that unsuccessful Nil checks only occur when the structure of the chromatic tree changes sometime after TryRebalance is invoked [2]. Lemma 6.65. Each invocation I of TryRebalance that fails a Nil check is concurrent with a operation that performs a successful SCX during I.
Intuitively, we can charge unsuccessful Nil checks to the update CAS that caused this change. We argue a dollar can always be withdrawn from B nil to pay for a failed Nil check when required by W-CONFLICT. Proof. Suppose s is a step that applies W-NIL for a cleanup phase cp. We argue that in the configuration C − before s, B nil (cp, C − ) ≥ 1. By Lemma 6.65, a failed Nil check can only occur due to a concurrent update CAS sometime during cp's instance of TryRebalance. Therefore, there exists at least 1 update CAS in the execution interval of the current attempt of cp that applied D1-NIL, depositing 1 dollar into B nil (cp). Since cp only withdraws 1 dollar in each failed attempt, B nil (cp, C − ) ≥ 1.

The B Account
In this section, we show that, for all update and cleanup phases xp, B(xp) has a non-negative balance. Since an update or cleanup phase can perform an arbitrary number of successful freezing CASs, an arbitrary number of dollars may be transferred from the B accounts by T1-B. We show B(xp, C) ≥ 0 for all update and cleanup phases xp and all configurations C. To do so, we instead give a function J(xp, C) such that B(xp, C) ≥ J(xp, C) ≥ 0. Recall that for any execution α and function f (x, C), we let f (x) denote f (x, C) as C varies over the configurations of α. The following definitions are used to define J. For any node x in the chromatic tree in configuration C, let • isF rozen(x, C) be 1 if x is frozen in C, and 0 otherwise, • sib(x, C) to be sibling node of x in C, • par(x, C) to be parent node of x in C if x = entry, and • npa(x, C) be the set of nodes that are not proper ancestors of x in the chromatic tree in C.
For any node or phantom node x in the extended tree T * in configuration C, let • depth(x, C) be the number of edges along the path from phantomRoot to x in C.
For each node x that is in the chromatic tree at some point in an execution, we define an auxiliary Boolean variable abort(x) that is initially 0. The abort variables are updated by the following four rules: • A1: A successful freezing CAS on a downwards node x sets abort(par(x)) = 1.
• A2: A successful freezing CAS on a cross node x sets abort(x) = 1.
• A4: The completion of an update or cleanup attempt sets abort(x) = 0 for all nodes x except for those on which LLX(x) has been performed in the latest attempt of an active operation.
We begin with a technical lemma.
Lemma 6.67. Let r be a node that is unfrozen by an abort step belonging to an instance of S SCX. Let C − be the configuration immediately before the abort step and let C r the configuration immediately after the successful LLX on r linked to S. If there exists a configuration C ′ between C r and C − such that abort(r, C ′ ) = 1, then abort(r, C − ) = 1.
Proof. Suppose for contradiction, that abort(r, C − ) = 0. Then there exists some step s between C ′ and C − that either applies A3 or A4, changing abort(r) to 0. We consider each of these cases in turn.
• Case 1: Suppose step s applies A3. Then s is a successful abort step that unfreezes r. There is only 1 successful abort step belonging to S, which occurs in the step after C − , so s is not an abort step belonging to S. So s unfreezes r after the successful freezing CAS fcas ′ on r belonging to some instance S ′ = S of SCX. Note that since r is unfrozen by an abort step belonging to S, there exists a successful freezing CAS fcas on r belonging to S in some configuration between C r and C − . Since r is frozen for S in all configurations after fcas but before C − , fcas ′ occurs before fcas. After fcas ′ , r.info no longer points to the same SCX-record read by the LLX on r linked to S. This implies that any freezing CASs on r belonging to S will fail. This contradicts the fact that fcas is a successful freezing CAS.
• Case 2: Suppose step s applies A4. Let A be the current attempt of the update or cleanup phase xp that invoked S. Rule A4 requires that no LLX on r has been performed for any active attempt of an update or cleanup phase. This contradicts the fact that a successful LLX on r has been performed by xp in A before s occurs.
We next show that unless abort(r, C) = 1, the step immediately following C is not a successful abort step that unfreezes node r.
Lemma 6.68. Consider the set R of nodes that are unfrozen by an abort step belonging to an instance S of SCX.
In the configuration C − prior to the abort step, abort(r, C − ) = 1 for each r ∈ R.
Proof. If R = ∅, then the lemma holds trivially. So suppose R = ∅. For each node in r ∈ R, there exists a successful freezing CAS on r belonging to S which occurs after the LLX on r linked to S, but before the abort step belonging to S. Furthermore, no field of r is modified between the LLX on r linked to S and the abort step belonging S since r is successfully frozen for S. Since each chromatic tree transformations involves a connected subtree of the chromatic tree, the nodes in R are a connected subtree in all configurations between the first LLX linked to S and C − . First we argue abort(k, C − ) = 1 for any cross node k in R. By inspection of the chromatic tree transformations, there is at most 1 cross node. When k is successfully frozen for S, abort(k) is set to 1 by rule A2. By Lemma 6.67, abort(k, C − ) = 1.
Next we argue that for each downward node d ∈ R, abort(d, C − ) = 1. Let the downward nodes in R enumerated in the order that they are frozen be d 1 , . . . , d t . By inspection of the chromatic tree transformations, the first node frozen for each transformation is a downward node, so t ≥ 1 since R = ∅. Let the successful freezing CASs on d 1 , . . . , d t be c 1 , . . . , c t respectively.
First we argue abort(d i , C − ) = 1 for 1 ≤ i < t. To do so, we show that c i+1 sets abort(d i ) = 1. Since d i is a downward node, the next node frozen for S is a child of d i . If the next node frozen for S after d i is d i+1 , then c i+1 sets abort(d i ) = 1 by rule A1. If the next node frozen for S after d i is the cross node k, then the node frozen for S after k is the sibling of k. There is only one cross node for S, so the sibling of k is the downward node following d i , namely d i+1 . Thus d i is the parent of d i+1 , so c i+1 sets abort(d i ) = 1 by rule A1. In either case, by Lemma 6.67, abort(d i , C − ) = 1.
Finally we argue abort(d t , C − ) = 1. Suppose the failed freezing iteration belonging to S be for a node x. If d t is the last node frozen for S, then x is a child of d t by the definition of downward nodes since x is the next node frozen after d t . If d t is not the last node frozen for S, then the last node frozen for S is the cross node k. Then d t is the parent of k, and k is the sibling of x, so d t is also a parent of x.
The freezing CAS on x belonging to S fails, so there exists a freezing CAS c ′ x on x for an SCX S ′ = S that occurs sometime after the LLX on x linked to S. This freezing CAS sets abort(d t ) = 1 by rule A1. By Lemma 6.67, abort(d t , C − ) = 1. Therefore, abort(r, C − ) = 1 for each r ∈ R.
The definition of J(cp, C) uses another function H(x, C), which maps node x in the chromatic tree in configuration C to an integer. For any node x in the chromatic tree in configuration C, let H(x, C) = 3h(C) + 12 − 3depth(x, C) + 6ċ(C) + u∈npa (x,C) [abort(u, C) − isF rozen(u, C)].
The terms 6ċ(C) and 3h(C) terms are only included to ensure that H remains positive. Lemma 6.69. For any node x in the chromatic tree in configuration C, 0 ≤ H(x, C) ≤ 3h(C) + 12ċ(C) + 12.
Proof. In configuration C, there are at mostċ(C) active operations. Each of these may have up to 6 distinct nodes frozen (for example, if all operations are performing a W3 or W4 transformation), so the summation term in H has a minimum value of −6ċ(C). Likewise, at most 6ċ(C) nodes u have abort(u) = 1, so the summation term in H has a maximum value of 6ċ(C). Finally, 0 ≤ depth(u, C) ≤ h(C) + 4 for all nodes u, since the height of an extended tree T * is greater than T by 4. Taking the minimum and maximum values of the summation term in H and depth(u, C) gives 0 ≤ H(u, C) ≤ 3h(C) + 12ċ(C) + 12.
Next we prove additional properties of H required for our analysis. For any node x in configuration C, let γ(x, C) = abort(x, C) − isF rozen(x, C). Lemma 6.70. For any node x and configuration C, −1 ≤ γ(x, C) ≤ 1.
For any function f (x) with value f (x, C) in configuration C, we define ∆f (x, C) = f (x, C) − f (x, C − ), where C − is the configuration immediately before C. Lemma 6.74. A successful freezing CAS on a downward node x for an SCX decreases H(x) by at least 1, and does not increase H(u) at any other node u = x in the chromatic tree.
Proof. Let C be the configuration immediately after the freezing CAS. The freezing CAS on the downward node x sets isF rozen(x) = 1. Additionally, by rule A1 of the abort variable, the freezing CAS sets abort(p) = 1, where p is the parent of x. Consider an arbitrary node u in the chromatic tree. We consider how the value of H changes for u after the freezing CAS, depending on the location u in the chromatic tree: • Case 1: Suppose x ∈ npa(u, C) and p / ∈ npa(u, C). So u is a proper descendant of p and not a proper descendant of x. Since ∆isF rozen(x, C) = 1, it follows that ∆H(u, C) = −1. When u = x, this proves H(x) decreases by 1.
• Case 2: Suppose x, p / ∈ npa(u, C). So u is a proper descendant of p and a proper descendant of x. Therefore ∆H(u, C) = 0 since no terms in H(u) change due to the freezing CAS.
The case where x / ∈ npa(u, C) and p ∈ npa(u, C) cannot occur. In all possible cases, ∆H(u, C) ≤ 0, and so H(u) does not increases for any node u in the chromatic tree. Lemma 6.75. A successful freezing CAS on a cross node x for an SCX does not increase H(u) at any node u in the chromatic tree.
Proof. Let C be the configuration immediately after the freezing CAS. The freezing CAS on the cross node x sets isF rozen(x) = 1. By rule A2 of the abort variable, the freezing CAS sets abort(x) = 1. Consider any node u in the chromatic tree. If x ∈ npa(u, C), then ∆isF rozen(x, C) = 1 and ∆abort(s, C) ≤ 1, it follows that ∆H(u, C) ≤ 0. If x / ∈ npa(u, C), then ∆H(u, C) = 0 since no terms in H(u) change due to the freezing CAS.
Lemma 6.76. An abort step for an invocation S of SCX does not change H(u) for any node u in the chromatic tree.
Proof. The abort step unfreezes all nodes that were previously frozen for S. Let the set of nodes that are unfrozen by the abort step be R. The abort step then changes isF rozen(r) from 1 to 0 for each r ∈ R since r is no longer frozen after the abort step. Additionally, by Rule A3 of abort, we set abort(r) = 0 when r is unfrozen. By Lemma 6.68, abort(r, C − ) = 1 for each r ∈ R in the configuration C − immediately before the abort step. Therefore, every increase in H due to a change in isF rozen(r) from -1 to 0 is balanced by a decrease in abort(r) from 1 to 0. So H(u) does not change for any node u in the chromatic tree after the abort step.
Next, we give the final definitions needed to define J(xp, C).
Definition 6.77. For an update or cleanup phase xp and configuration C, let focalPath (xp, C) be the set of all nodes along the path from entry to focalNode(xp, C), inclusive.
The nodes in this set have the following useful property.
Lemma 6.78. Consider a configuration C during a cleanup phase cp. For every node x in focalPath (cp, C), x is on cp's search path in C.
Proof. By Lemma 6.54, focalNode(cp, C) is on cp's search path in C. The unique path of nodes from entry to focalNode(cp, C) are also on cp's search path in C, which by definition are the nodes in focalPath (cp, C).
Definition 6.79. For every cleanup phase cp and every node x in the chromatic tree at the beginning of cp, we define backup(cp, x) = 0. When an update CAS adds a new node x into the chromatic tree during cp, backup(cp, x) is initialized to 1 if x is on focalPath(cp), and 0 otherwise. Finally, a step that removes a node x from focalPath(cp) sets backup(cp, x) = 0.
For convenience, we let backup(up, x, C) = 0 for all update phases up, nodes x, and configurations C.
Lemma 6.80. If there exists a configuration C during a cleanup cp where a node x is a proper descendant of focalNode(cp, C), then backup(cp, x, C ′ ) = 0 for all configurations C ′ after C.
Proof. Let C x be the first configuration in which x is in the chromatic tree. If backup(cp, x, C x ) = 0, then backup(cp, x, C ′ ) = 0 since backup(cp, x) is only initialized to 1 when x is added to the chromatic tree. So suppose backup(cp, x, C x ) = 1, and so x ∈ focalPath(cp, C x ). Since x is a proper descendant of focalNode(cp, C), x / ∈ focalNode(cp, C). Thus, there exists a step between C x and C that removes x from focalPath(cp). This step sets backup(cp, x) to 0, and so backup(cp, x, C ′ ) = 0.
Finally, for an update or cleanup phase xp and configuration C, we define the function If xp is not active in C, define J(xp, C) = 0. Note that the second summation in J is only non-zero when xp is a cleanup phase.
Observation 6.81. For every update or cleanup phase xp and every configuration C in an execution, J(xp, C) ≥ 0.
Proof. By Lemma 6.69, H(x, C) ≥ 0 for all x and C. Since it is the summation of H functions and backup Boolean variables, J(xp, C) ≥ 0.
We prove that B(xp, C) ≥ J(xp, C) for every configuration C. The purpose of the first summation in J is to decrease J whenever a successful freezing CAS is performed on a downwards node x ∈ targets(xp, C). By Lemma 6.74,H(u) decreases by at least 1 and no other H term increases. Thus, J decreases by at least 2 as the result of the freezing CAS on x. Since T1-B transfers 1 dollar from B(xp) to each of B llx (xp, x) and B scx (xp, x) after the successful freezing CAS on x, the invariant cannot be violated by the freezing CAS.
The purpose of the second summation in J is illustrated in the following example. Let cp be a cleanup phase by a process P . Consider an update CAS from a configuration C that removes focalNode(cp, C) = location(P, C) from the chromatic tree. Let C ′ be the configuration immediately following C. Since location(P, C) is no longer in the chromatic tree, by Definition 6.50.3, focalNode(cp, C ′ ) = nextNode(P, C ′ ). Thus, the first summation in J may change since targets(cp, C ′ ) is not necessarily equal to target(cp, C). If the depth of nextNode(P, C ′ ) in C ′ is less than the depth of location(P, C) in C, then we can show that the first summation in J may increase by an amount proportional to the difference in depth. This scenario occurs when cp must pop many nodes off its stack during backtracking before it visits a node in the chromatic tree. These nodes on cp's stack were removed from the chromatic tree after they were pushed onto the stack. When nodes were removed from the chromatic tree, a proportional number of new nodes were added into focalPath (cp). A new node v added into focalPath(cp) will have backup(cp, v) = 1. When focalNode(cp) changes from location(P, C) to nextNode(P, C ′ ), many nodes v with backup(cp, v, C) = 1 will be removed from focalPath(cp, C). This decrease in the second summation of J multiplied by a sufficiently large constant offsets the increase in the first summation of J.
In the following lemmas, we show how various steps change J. In particular, we will show that only update CASs and commit steps can increase J(cp), and only increase J(cp) by a constant amount.
To show how J changes as a result of a cleanup phase cp visiting new nodes, we first consider how a summation of H values may change.
Lemma 6.82. For any node x and its parent p in the chromatic tree in configuration C, Proof. Without loss of generality, assume x is the left child of p. Figure 17 shows an example of rebalSet(p, C) and rebalSet(x, C). We define a mapping ψ from each node u ∈ rebalSet(p, C) to a node in rebalSet(x, C). If u ∈ rebalSet(p, C) − rebalSet(x, C), ψ maps u to a node in rebalSet(x, C) − rebalSet(p, C). If u ∈ rebalSet(p, C) ∩ rebalSet(x, C), ψ(u) = u. Therefore, Upper bound Lower bound n 1 n 10 ≤ 20 ≥ 10 n 5 n 11 ≤ 8 ≥ 4 n 8 and n 9 n 16 and n 17 resp. ≤ 6 ≥ 0 n 12 , n 13 , n 14 and n 15 n 18 , n 19 , n 20 and n 21 resp. ≤ 8 ≥ −2 Steps that update a process P 's local variable l in BacktrackingCleanup may change J for a cleanup phase cp due to a change in its focal node, and thus a change in targets(cp). The following lemmas show that these steps do not increase J. Lemma 6.83. Consider a process P in cleanup phase cp in configuration C. Let C − be the configuration immediately before C. If the structure of the chromatic tree is the same in C − and C, and focalNode(cp, C) is a (not necessarily proper) descendant of focalNode(cp, C − ), then ∆J(cp, C) ≤ 0.
Proof. Let the configuration immediately before C be C − . We first consider how the first summation in J may change. Since the chromatic tree is the same in C − and C, it follows by definition that H(u, C) = H(u, C − ) and rebalSet(u, C) = rebalSet(u, C − ) for all nodes u in the chromatic tree. Let k = depth(focalNode(cp, C), C) − depth(focalNode(cp, C − ), C). Since focalNode(cp, C) is a descendant of focalNode(cp, C − ), k ≥ 0. Let n 1 , . . . , n k+1 be the nodes on the path from n 1 = focalNode(cp, C − ) to n k+1 = focalNode(cp, C). By Lemma 6.82, for 1 ≤ i ≤ k, It follows that u∈rebalSet(n k+1 ,C) By definition, targets(cp, C) = rebalSet(n k+1 , C) and targets(cp, C − ) = rebalSet(n 1 , C − ). Since rebalSet(n 1 , C − ) = rebalSet(n 1 , C), it follows that u∈targets(cp,C) By definition, focalPath(cp, C) = focalPath (cp, C − ) ∪ {n 2 , . . . , n k+1 }. For 2 ≤ i ≤ k + 1, n i is a descendant of n 1 in C − , so by Lemma 6.80, backup(cp, n i , C) = 0. Therefore, the second summation of J does not change as a result of the newly added nodes in focalPath(cp, C). Therefore, ∆J(cp, C) ≤ −12k ≤ 0, since k ≥ 0. Lemma 6.84. Consider a step s of a process P in cleanup phase cp that updates P 's local variable l to point from a node p to its child x. If C is the configuration after s, then ∆J(cp, C) ≤ 0.

Proof.
Step s does not change the structure of the chromatic tree. Let the configuration immediately before C be C − . By definition, location(P, C − ) = p and location(P, C) = x. We argue that focalNode(cp, C) is a descendant of focalNode(cp, C − ). We consider several cases. • Case 2: Suppose currentV iol(P, C − ) = Nil and location(P, C − ) is in the chromatic tree. By Definition 6.50.2, focalNode(cp, C − ) = location(P, C − ) = p. Since p is in the chromatic tree and x is a child of p, x is also in the chromatic tree. If currentV iol(P, C) = Nil, then by Definition 6.50.2, focalNode(cp, C) = location(P, C) = x. Otherwise currentV iol(P, C) = x, then by Definition 6.50.1, focalNode(cp, C) = x. In either case, focalNode(cp, C) is a descendant of focalNode(cp, C − ).
• Case 3: Suppose currentV iol(P, C − ) = Nil, and location(P, C − ) is not in the chromatic tree. By Definition 6.50.3, focalNode(cp, C − ) = nextNode(P, C − ). By definition, nextNode(P, C − ) is the first node in the chromatic tree that P will visit in a solo execution starting from C − . Notice that P 's solo execution starting from C − begins with s. There are two cases depending on location(P, C), the node visited by P during s.
We can prove a similar result to Lemma 6.84, except for the case when l is updated to point to the topmost node on P 's stack. The following lemmas are used to prove this case. Lemma 6.85. Let x be any node, not necessarily in the chromatic tree. Let y be a node in the chromatic tree immediately before and after a chromatic tree transformation T . If y is on the search path for a key k from x before T , then y is on the search path for k from x after T .
Proof. Consider the node u whose pointer is updated by T . If u is not on the search path for k from x, then no pointer along the path from x to y is changed. Therefore, y is on the search path for k from x after T .
So suppose u is on the search path for k from x. Then by Observation 5.12.4, the nodes reachable from u before T are reachable from u after T , except for the nodes in the set R removed by T . So only nodes in R are removed from the search path for k from x. Since y is not removed by T , y is still on the search path for k from x after T . Corollary 6.86. Suppose a node y is in the chromatic tree and on the search path for a key k from a node x in a configuration C ′ . If y is still in the chromatic tree in a later configuration C, then it is still on the search path from x in C. Lemma 6.87. Let C ′ be a configuration during a process P 's cleanup phase, and suppose node x is on P 's search path from location(P, C ′ ). If x is still in the chromatic tree in a later configuration, C, and x is not on P 's search path from location(P, C), then there exists a step between C ′ and C in which x is pushed onto P 's stack.
Proof. By the properties of SCX, nodes removed from the chromatic tree are never added back to the chromatic tree, so x is not removed from the chromatic tree between C ′ and C. So x is in the chromatic tree in all configurations between C ′ and C. By Lemma 5.3, x is on P 's search path in all configurations between C ′ and C.
Let C ′′ be the last configuration between C ′ and C in which x is on P 's search path from location(P, C ′′ ). Let s be the step following C ′′ . An update CAS by any process does not change location(P ). By Lemma 6.85, x remains on the P 's search path from location(P, C ′′ ) after s. Thus, s is not an update CAS and the structure of the chromatic tree is not changed by s. So s must change location(P ) by an update to P 's local variable l. The lines of code where this occurs are on lines 5, 8, and 18.
Suppose s updates l to point to a node t popped by line 5 or line 8 of BacktrackingCleanup. Let α ′ be the prefix of the execution up to C ′′ . By Lemma 5.15, there is a path in G α ′ from t to location(P, C ′′ ). Since x is on P 's search path from location(P, C ′′ ), there is a path from t to x in G α ′ . For any node y from any path from t to x in G α ′ , consider an update CAS in α ′ that modifies a child pointer of y. By Observation 5.124, since x is not removed from the chromatic tree by this update CAS, x is reachable from y after the update CAS. Therefore, x is reachable from t in C ′′ . This implies that x is on P 's search path from t after s, since s does not modify the chromatic tree. Since P 's local variable l points to t in the configuration following s, this contradicts the fact that C ′′ is the last configuration in which x is on P 's search path from location(P, C ′′ ).
Therefore, s updates P 's local variable l to point to a child node on line 18. Since l is updated to the next node on P 's search path from location(P, C ′′ ), x can only be removed from P 's search path if location(P, C ′′ ) = x. This implies that x was pushed onto P 's stack on line 17 immediately prior to when P executes line 18 during s. Lemma 6.88. Let C ′ be a configuration during a process P 's cleanup phase, and suppose node x is on P 's search path from location(P, C ′ ). If x is still in the chromatic tree in a later configuration, C, and x is not on P 's search path from location(P, C), then one of the following statements are true: 1. x is on P 's stack in C, or 2. during P 's cleanup attempt containing C, x was popped off P 's stack on lines 11 or 12 of Backtracking-Cleanup.
Proof. Note that if Statement 2 is true, then x is not on P 's stack in C since no pushes are performed in a cleanup attempt after line 12 is executed. Thus, both statements cannot be true. Suppose, for contradiction, that both statements are false. This occurs when x is not on P 's stack in C, and x was not popped from the stack on lines 11 and 12 of P 's latest cleanup attempt containing C. Let C ′′ be the last configuration between C ′ and C in which x is on the P 's search path from location(P, C ′′ ) in C ′′ . By Lemma 6.87, there exists a step between C ′′ and C in which x is pushed onto P 's stack. Since x is not on P 's stack in C, x is popped off P 's stack sometime after it is last pushed onto the stack. Let C pop be the configuration immediately before this pop.
Suppose x was popped after line 5 or line 8 is executed. Then P 's local variable l points to x in C pop . This contradicts the fact that C ′′ is the last configuration in which x is on P 's search path from its location.
So suppose x is popped on lines 11 and 12. By assumption, P does not pop x off its stack on lines 11 and 12 during its attempt containing C, so C pop belongs to a prior attempt A. Let t be the last node popped during backtracking in the attempt A ′ after A. By the definition of backtracking, t is unmarked in the configuration immediately before it is popped in A ′ , and hence in the chromatic tree. By Lemma 5.20, since x is above t on P 's stack in C pop , x is on P 's search path from t in C pop . In the configuration C ′ pop immediately after t is popped in A ′ (either on line 8 or 5), t = location(P, C ′ pop ). Since x is on P 's search path from t in C pop , by Lemma 6.85, x is on P 's search path from t in C ′ pop . This contradicts the fact that C ′′ is the last configuration in which x is on P 's search path from location(P, C ′′ ). Lemma 6.89. Consider an update CAS ucas, and let the configurations immediately before and after ucas be C − and C respectively. Suppose x is a node in the chromatic tree in C − and C. Let P be a process in a cleanup phase cp and nextNode(P, C) = Nil. If x is not on a process P 's search path in C − and on P 's search path in C, then in C, • if location(P, C) is the chromatic tree, x is on P 's search path from location(P, C), • otherwise x is on P 's search path from nextNode(P, C).
Proof. Suppose ucas updates the pointer to a node u, removing a set of nodes R from the chromatic tree. If x is not a descendant of u, then ucas does not move x onto P 's search path. So suppose x is a descendant of u. Since x is not removed from the chromatic tree, x / ∈ R. Let k be the key of P 's current operation. Since P 's local variable l points to the same node in C − and C, location(P, C) = location(P, C − ).
Let the key range of a node x be the set of keys in which x is on the search path from entry. It can be verified by inspection of the chromatic tree transformations that only the Delete transformation can add a new key to the key range of x after x has been added to the chromatic tree. Without loss of generality, suppose ucas deletes a left leaf (i.e the transformation shown in Figure 5), which removes a node u x , its left child u xl , and right child u xr , and adds a new node n. The key range of u xl before ucas is added to each node on the leftmost path of the subtree rooted at n. No other key ranges change as a result of ucas. So suppose k is in key range of u xl , and x is on the leftmost path of the subtree rooted at n.
Suppose location(P, C) is in the chromatic tree in C. So location(P, C) is in the chromatic tree in C − since it is not a new node added by ucas. By Corollary 5.17 and Lemma 5.3, location(P, C) is on the search path for k in C − and C. The only nodes in the chromatic tree in C − with k in their key range and are still in the chromatic tree in C are those on the path from entry to u. Therefore, location(P, C) is a node on the path from entry to u in C. Therefore, x is on P 's search path from location(P, C) in C.
Suppose location(P, C) is not in the chromatic tree in C, but was in the chromatic tree in C − . So location(P, C) was removed from the chromatic tree by ucas. By Corollary 5.17 and Lemma 5.3, location(P, C) is on P 's search path in C − , and so is a node on the path from u to u xl in C − . Since there are no nodes in the chromatic from location(P, C) to the leaf u xl in C, by Lemma 6.47, nextN ode(P, C) is a node t on P 's stack that is in the chromatic tree in C. Note that since P 's stack is the same in C − and C, t is also on P 's stack in C − . By Lemma 5.18, the nodes on P 's stack in C − are on P 's search path in C − . Thus, t is a node on the path from entry to u in C. Therefore, x is on P 's search path from nextN ode(P, C) in C.
Suppose location(P, C) is not in the chromatic tree in C or C − . By Lemma 6.52, focalNode(cp, C − ) = nextN ode(P, C − ). By Lemma 6.54, nextN ode(P, C − ) is on P 's search path in C − . Thus, nextN ode(P, C − ) is a node on the path from entry to u xl in C − . If nextN ode(P, C − ) is still in the chromatic tree in C, then nextN ode(P, C) = nextN ode(P, C − ) and is a node on the path from entry to u. Since x is a proper descendant of u and added to P 's search path, x is on P 's search path from nextN ode(P, C) in C. If nextN ode(P, C − ) is not in the chromatic tree in C, then it is a node removed by ucas. There are no nodes in the chromatic tree from nextN ode(P, C − ) to the leaf u xl in C. By Lemma 6.47, nextN ode(P, C) is a node t on P 's stack that is in the chromatic tree in C. Note that since P 's stack is the same in C − and C, t is also on P 's stack in C − . By Lemma 5.18, the nodes on P 's stack in C − are on P 's search path in C − . Thus, nextN ode(P, C) is a node on the path from entry to u in C. Therefore, x is on P 's search path from nextN ode(P, C) in C. Lemma 6.90. Consider a step s by a process P in a cleanup phase cp that pops a node from its stack and updates its local variable l to point to this node. If C is the configuration immediately after s, then ∆J(cp, C) ≤ 0.
Proof. Note that, from the code, the pop by s is performed on lines 5 and 8 of BacktrackingCleanup. These pops are performed during backtracking, and so s does not belong to the first attempt of cp. Let m be the node popped by s, so location(P, C) = m. Let C − be the configuration immediately before C. We consider multiple cases, depending on if s contains the first pop in the current attempt A of cp.
• Case 1: Suppose the pop by s is not the first pop in A. So this pop occurs on line 8. We first argue that focalNode(cp, C − ) = nextNode(P, C − ). Let s ′ be a step prior to s in which a pop is last performed by cp. Let C ′ be the configuration immediately after s ′ , and let m ′ be the node popped by s ′ . From the code, P 's local variable l is set to m ′ by s ′ and is not updated again until s, so location(P, C − ) = m ′ . The node m ′ was marked in C ′ . Otherwise backtracking would have ended after s ′ by the following check on line 6 of BacktrackingCleanup, and hence s will not be performed during A. By Lemma 6.9, m ′ is removed from the chromatic tree before the next Pop for cp is performed. So location(P, C − ) is not in the chromatic tree in C − . By Lemma 6.52, focalNode(cp, C − ) = nextNode(P, C − ).
• Case 2: Suppose the pop by s is the first pop in A. Note that this pop occurs on line 5. Since s does not belong to the first attempt of cp, there exists an attempt A ′ prior to A. Note that C is the first configuration of A, and C − is the last configuration of A ′ . Note that A ′ ended after an invocation I of TryRebalance(ggp, gp, p, l).
Let the nodes pointed to by the local variables ggp, gp, p, and l at the start of I be ggp ′ , gp ′ , p ′ and v, respectively. From the code, no step modifies P 's stack between the start of I and s. Therefore, since m is the node popped by s, it was the topmost node on P 's stack at the start of I. From the code, ggp ′ is the top most node on P 's stack at the start of I, so ggp ′ = m. Additionally, no step modifies P 's local variable l between the start of I and s. From the code, l points to v at the start of I. Therefore, l points to v in C − , and so location(P, C − ) = v.
So suppose currentV iol(P, C − ) = Nil. Since m is on P 's stack in C − , by Lemma 5.11, m does not contain a violation. Therefore, s does not apply rule CV1 of Definition 6.43, and so currentV iol(P, C) = Nil. By Lemma 6.57 and Definition 6.43, either I is stale or an update CAS removed at least one of m, gp ′ , p ′ , or v sometime between the invocation of I and C − . In either case, least one of m, gp ′ , p ′ , or v is not in the chromatic tree in C − .
Let t be the topmost node on P 's stack that is in the chromatic tree in C − . We first argue that focalNode(cp, C) = t. Suppose m is not in the chromatic tree in C − , and so m = t. Then t is still the topmost node on P 's stack that is in the chromatic tree in C, so by Lemma 6.46, nextNode(P, C) = t. By Definition 6.50.3, focalNode(cp, C) = t. Now suppose m is in the chromatic tree in C − , and so m = t. Then location(P, C) = t is in the chromatic tree. Thus, by Definition 6.50.2, focalNode(cp, C) = location(P, C) = t. In either case, focalNode(cp, C) = t.
Suppose v is not in the chromatic tree in C − . By Lemma 6.46, nextN ode(P, C − ) = t. Since location(P, C − ) = v is not in the chromatic tree, by Definition 6.50.3, focalNode(cp, C − ) = nextNode(P, C − ) = t. Since focalNode(cp, C) = focalNode(cp, C − ), by Lemma 6.83, ∆J(cp, C) = 0. Now suppose v is a node in the chromatic tree in C − , and so focalNode(cp, C − ) = v by Definition 6.50.2. Therefore, cp's focal node changes from v to t. By Lemma 5.16, t is not reachable from v in C − . By Lemma 6.78, v is on cp's search path in C − , and by Lemma 5.18, t is on cp's search path in C − . So t is a proper ancestor of v in C − . Let k = depth(v, C − ) − depth(t, C − ) ≥ 1. Let the sequence of nodes on the path from t to v in C − be t, w 1 , . . . , w k−1 , v . We prove a series of claims that apply in this case. Proof of Claim 1. Consider the update CAS ucas that updates the pointer of a node u and removes at least one of m, gp ′ , or p ′ from the chromatic tree. Since m, gp ′ , and p ′ are internal nodes, ucas is not an Insert transformation. Suppose ucas removes a connected set of nodes rooted at a node r. By inspection of the remaining transformations of Figure 5, any path through the chromatic tree that passes through r before the transformation will pass through at least one new internal node after the transformation. Thus, there is at least one node w on the path between t and v in C − . Since m, gp ′ , p ′ , and v are the last nodes visited by P before C − , which includes at least one of the nodes removed by ucas, P does not visit any of nodes added into the chromatic tree by ucas. Thus, w = p ′ , gp ′ . So, |{w 1 , . . . , w k−1 } − {p ′ , gp ′ }| ≥ 1.
Claim 2. For each w ∈ {w 1 , . . . , w k−1 } − {p ′ , gp ′ } and for all configurations C ′ during cp up to an including C − , w is not on P 's search path from location(P, C ′ ) in C ′ .
Proof of Claim 2. Suppose w is on P 's stack in C − . Since t and w are in the chromatic tree and w is on the path from t to v, then by Lemma 5.20, w will appear above t on P 's stack in C − . This contradicts the fact that t is the topmost node on P 's stack that is in the chromatic tree in C − . So suppose w is not on P 's stack in C − . By definition, w = p ′ , gp ′ . Note that p ′ and gp ′ are the nodes popped off P 's stack on lines 11 and 12 of A ′ . Furthermore, w is not on P 's search path from location(P, C − ) = v in C − . Hence, by Lemma 6.88, w is not on cp's search path from location(P, C ′ ) in C ′ for all configurations C ′ prior to C − .
Claim 3. For each w ∈ {w 1 , . . . , w k−1 } − {p ′ , gp ′ } and for all configurations C ′ during cp up to an including C − , w is not on P 's search path from nextN ode(P, C ′ ) in C ′ Proof of Claim 3. Suppose, for contradiction, that there exists a configuration C ′ prior to C − in which w is on cp's search path from nextN ode(P, C ′ ) in C ′ . In configuration C − , P visits v = location(P, C − ), which is a node in the chromatic tree. Hence, by Lemma 6.48, there exists a configuration C ′′ between C ′ and C − in which cp visits nextN ode(P, C ′ ). So location(P, C ′′ ) = nextN ode(P, C ′ ). By Corollary 6.86, w is on P 's search path from location(P, C ′′ ) in C ′′ . This contradicts the Claim 2. So there is no configuration C ′ prior to C − in which w is on cp's search path from either location(P, C ′ ) or nextN ode(P, C ′ ). Proof of Claim 4. Since w ∈ focalPath (cp, C − ), then by Lemma 6.54, w is on cp's search path in C − . Let C s be the first configuration during cp in which w is on cp's search path. Let C w be the first configuration during cp in which w is in the chromatic tree. Suppose w is not on cp's search path in C w . Then there exists an update CAS ucas after the start of cp that adds w onto cp's search path. By Lemma 6.89, in C s , w is on cp's search path from location(P, C s ) in C s if location(P, C s ) is in the chromatic tree, or from nextN ode(P, C s ) if location(P, C s ) is not in the chromatic tree. This either contradicts Claim 2 or Claim 3. So w is on cp's search path in C w . Since w is in the chromatic tree in all configurations between C w and C − , by Lemma 5.3, w is on cp's search path in all configurations between C w and C − . If w was added to the chromatic tree before the start of cp, then C w is the start of cp. So w is on cp's search path from location(P, C w ) = entry, a contradiction. Therefore, w was added to the chromatic tree after the start of cp.
Suppose there exists a configurationĈ between C w and C − in which w is not in focalPath(cp,Ĉ). Since w is on cp's search path inĈ, w is a proper descendant of focalNode(cp,Ĉ). By Lemma 6.52 and Lemma 6.51, focalNode(cp,Ĉ) is either nextN ode(P,Ĉ) or a descendant of location(P,Ĉ). Thus, w is on cp's search path from either nextN ode(P,Ĉ) or location(P,Ĉ) inĈ. This either contradicts Claim 3 or Claim 2.
So for all configurationsĈ between C w and C − , w is in focalPath(cp,Ĉ). In particular, w is in focalPath (cp, C w ), and so backup(cp, w, C w ) = 1. Furthermore, there is no configuration between C w and C − in which w is removed from focalPath(cp). Therefore, no step sets backup(cp, w) = 0 between C w and C − . It follows that backup(cp, w, C − ) = 1.
By Claim 1 and 4, it follows that This function has a maximum value of 0, which occurs when k = 4. Therefore, ∆J(cp, C) ≤ 0.
We next give an upper bound on the change in J(xp) as a result of an update CAS for any chromatic tree transformation. Unlike steps that update a process's local variable l which may occur an unbounded number of times per operation, there is only 1 successful update CAS per update phase, and at most 1 successful update CAS per violation removed from the chromatic tree. We show that ∆J(xp) is bounded above by a constant.
The following lemmas state that for any t ∈ targets(xp, C), H(t, C) − H(focalNode(xp, C), C) is bounded by constants. Proof. Since the targets of an Insert operation are a subset of those of a Delete operation, it is sufficient to prove the lemma assuming up is a Delete operation. Let targets(up, C) = {f, s, p, gp, ggp}, where s is the sibling of f and p, gp, and ggp are the three closest proper ancestors of f . (See Figure 19). Since an update CAS changes the structure of the chromatic tree, the H values of nodes that are still in the chromatic tree after an update CAS may change. The following lemma gives an upper bound on this change. Lemma 6.93. Consider an update CAS ucas for any transformation, where C − and C are the configurations before and after ucas respectively. If x is a node in the chromatic tree in both C − and C, then H(x, C) − H(x, C − ) ≤ 19.
Proof. Suppose ucas changes the pointer of a node u, removing a set of nodes R from npa(x, C − ) and adding a set of nodes A into npa(x, C). By inspection of each transformation, the height of the chromatic tree can increase by at most 2, i.e. h(C)−h(C − ) ≤ 2. Additionally, x can decrease in depth by at most 1, i.e. depth(x, C − )−depth(x, C) ≤ 1. We next give an upper bound on ∆J(up, C) for an update phase up as a result of an update CAS.
Lemma 6.94. Consider an update CAS ucas for any transformation. If C is the configuration immediately after ucas is performed, then for any update phase up active in C, ∆J(up, C) ≤ 450.
Proof. Let C − be the configuration before C. Suppose ucas changes the pointer of a node u, removing nodes the R from the chromatic tree and adding nodes A to the chromatic tree. Let t be any node in targets(up, C), and t − be any node in targets(up, C − ). We next argue that H(t, C) − H(t − , C − ) ≤ 45. Let f − = focalNode(up, C − ) and f = focalNode(up, C). We consider two cases, depending on whether f − is removed by ucas.
• Suppose f − is not removed by ucas. By definition, f − is the leaf node on up's search path in C − . Since f − is still in the chromatic tree in C, by Lemma 5.3, f − is still on up's search path in C. By inspection of the • Suppose s is the completion of an attempt of an update or cleanup phase xp that does not complete an operation. By rule A4 of abort variables, abort(u) may change from 1 to 0 for some nodes u in the chromatic tree. No other variables change as a result, and so for any update or cleanup phase xp ′ , ∆J(xp ′ ) ≤ 0. The B accounts do not change as a result of s, so ∆B(xp ′ , C) ≥ ∆J(xp ′ , C).
• Suppose s is the completion of an operation that was in its update or cleanup phase xp. Then J(xp, C) = 0 since xp is no longer active. By Observation 6.81, J(xp, C − ) ≥ 0, so ∆J ( Since all bank accounts have non-negative balance, Property P3 of the bank is satisfied.

Conclusion
We have shown that the amortized step complexity of an implementation of a non-blocking chromatic tree is O(ċ(α)+log n(op)). It would be interesting to see if amortized step complexity O(ċ(op)+log n(op)) can be shown for the chromatic tree. This is more challenging because one must argue that an operation with high contention does not perform an excessive amount of rebalancing. This may require a more detailed analysis of the chromatic tree than what is shown by Theorem 4.3. Alternatively, one may try to show a lower bound of Ω(ċ(α) + log n(op)). Finally, we believe that the techniques presented here can be applied to other balanced binary search tree implementations using LLX and SCX.