A contention adapting approach to concurrent ordered sets

Jiffy: A Lock-free Skip List with Batch Updates and Snapshots

“…Sagonas et al proposed a number of contention-adapting (CA) tree-based data structures with linearizable range scans. The data structures feature a lock-based [43,44] or a lock-free binary search tree [51] as the main part of the index, where each leaf node is a variable-size container, i.e., an AVL tree, a skip list or an immutable data structure that holds multiple key-value entries (which is similar to a revision in Jiffy). The size of the container is adjusted to the observed contention level (we discuss the differences with our index autoscaling policy in Section 3.3.6).…”

“…Our autoscaling policy is completely different from the one from [43,44,51], which relies on observing contention on shared references to containers (revisions). The CAS operations on these references are performed by updates and range scans.…”

“…We implemented Jiffy in Java and experimentally compared it with SnapTree [12], k-ary tree [13,14], CA-imm (lock-based contentionadapting tree with immutable containers) [43], CA-AVL and CA-SL (lock-based CA trees with mutable containers based on AVL trees and skip lists, respectively) [44] and LFCA tree (lock-free CA tree with immutable containers) [51] (see also Section 2). All of these ordered indices feature linearizable range scans.…”

“…We implemented Jiffy in Java and extensively tested it on various workloads against the state-of-the-art lock-free ordered indices that feature linearizable range scans [12][13][14]44] and the (lock-based) ordered indices that also support batch updates [51]. Our tests show the highly scalable performance of Jiffy, which is comparable or exceeds the performance of the other systems.…”

“…Smaller revisions are more suited for write-heavy workloads whereas large revisions benefit read-dominated workloads, especially when they feature many range scan operations. Automatic adaptation to the workload is accomplished on per-revision basis through a simple, yet versatile policy based on monitoring the time concurrent threads spend executing update (i.e., put, remove and batch update) and read (i.e., lookup or range scan) operations, not by counting the number of operations performed or monitoring the contention on shared references, as in other existing approaches, e.g., [43,44,51].…”