Optimistic concurrency with OPTIK

GuerraouiRachid,; TrigonakisVasileios,

doi:10.1145/3016078.2851146

Cited by 7 publications

(7 citation statements)

References 42 publications

(54 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In Figure 9, we provide results for the time spent waiting for locks and the number of restarted requests. Given that BST-TK uses trylocks [22], the waiting time for locks is normally 0. However, to better capture the effects of a slow thread on this algorithm, we depict the average time spent by threads on retries due to trylock failures.…”

Section: Unresponsive Threadsmentioning

confidence: 99%

Concurrent Search Data Structures Can Be Blocking and Practically Wait-Free

David

Guerraoui

2016

Proceedings of the 28th ACM Symposium on Parallelism in Algorithms and Architectures

Self Cite

View full text Add to dashboard Cite

We argue that there is virtually no practical situation in which one should seek a "theoretically wait-free" algorithm at the expense of a state-of-the-art blocking algorithm in the case of search data structures: blocking algorithms are simple, fast, and can be made "practically wait-free".We draw this conclusion based on the most exhaustive study of blocking search data structures to date. We consider (a) different search data structures of different sizes, (b) numerous uniform and non-uniform workloads, representative of a wide range of practical scenarios, with different percentages of update operations, (c) with and without delayed threads, (d) on different hardware technologies, including processors providing HTM instructions.We explain our claim that blocking search data structures are practically wait-free through an analogy with the birthday paradox, revealing that, in state-of-the-art algorithms implementing such data structures, the probability of conflicts is extremely small. When conflicts occur as a result of context switches and interrupts, we show that HTM-based locks enable blocking algorithms to cope with them.

show abstract

Section: Unresponsive Threadsmentioning

confidence: 99%

Concurrent Search Data Structures Can Be Blocking and Practically Wait-Free

David

Guerraoui

2016

Proceedings of the 28th ACM Symposium on Parallelism in Algorithms and Architectures

Self Cite

View full text Add to dashboard Cite

show abstract

“…First, a thread trying to become a combiner has to contend for an additional global lock. Second, inserting a node into the list head has to make a version check, 40,41 which can incur significant cache coherence traffic. Finally, it spends extra cost on traversing better than nondelegation locks, in particular those that omit NUMA feature such as the MCS and POSIX locks.…”

Section: High Contentionmentioning

confidence: 99%

A scalable lock on NUMA multicore

Yao

2020

Concurrency and Computation

View full text Add to dashboard Cite

Modern NUMA multicore architectures exhibit complicated memory behavior, such as cache coherence invalidation and nonuniform memory access where the access from a core to its local memory is significantly faster than crossnode access to memory on a different NUMA node. The complicated memory behavior has a large impact on the efficiency of locking synchronization, which affects the performance of parallel applications. Prior works offer several efficient designs to improve locking performance such as delegation schemes. However, the existing delegation schemes either occupy computing cores or provide nonscalable performance, or offer less portability. In this work, we present a NUMA-aware delegation lock that occupies no cores while offering scalable performance under high contention for NUMA multicore machines. The new lock is a variant of an efficient FFWD lock, and inherits its performance features, such as buffering responses within a NUMA node to minimize cache coherence traffic. Unlike FFWD, the new lock employs hierarchical NUMA-aware memory allocation and NUMA-aware dynamic server thread technique, to reduce crossnode communication between client and server threads. Our evaluation shows that the new lock outperforms FFWD under high contention, achieving the significant performance gains when compared with other state-of-the-art locks.

show abstract

“…Therefore, we only need to add one Byte to the header to implement the spinlock. Our seqlock implementation is inspired by the OPTIK design pattern [18].…”

Section: Cache and Kvs Implementation Detailsmentioning

confidence: 99%

Scale-out ccNUMA

Gavrielatos

Katsarakis

Joshi

et al. 2018

Proceedings of the Thirteenth EuroSys Conference

View full text Add to dashboard Cite

Today's cloud based online services are underpinned by distributed key-value stores (KVS). Such KVS typically use a scale-out architecture, whereby the dataset is partitioned across a pool of servers, each holding a chunk of the dataset in memory and being responsible for serving queries against the chunk. One important performance bottleneck that a KVS design must address is the load imbalance caused by skewed popularity distributions. Despite recent work on skew mitigation, existing approaches offer only limited benefit for high-throughput in-memory KVS deployments.In this paper, we embrace popularity skew as a performance opportunity. Our insight is that aggressively caching popular items at all nodes of the KVS enables both load balance and high throughput -a combination that has eluded previous approaches. We introduce symmetric caching, wherein every server node is provisioned with a small cache that maintains the most popular objects in the dataset. To ensure consistency across the caches, we use high-throughput fully-distributed consistency protocols. A key result of this work is that strong consistency guarantees (per-key linearizability) need not compromise on performance. In a 9-node RDMA-based rack and with modest write ratios, our prototype design, dubbed ccKVS, achieves 2.2× the throughput of the state-ofthe-art KVS while guaranteeing strong consistency.

show abstract

Optimistic concurrency with OPTIK

Cited by 7 publications

References 42 publications

Concurrent Search Data Structures Can Be Blocking and Practically Wait-Free

Concurrent Search Data Structures Can Be Blocking and Practically Wait-Free

A scalable lock on NUMA multicore

Scale-out ccNUMA

Contact Info

Product

Resources

About