A Pragmatic Implementation of Non-blocking Linked-lists

Harris, Timothy L.

doi:10.1007/3-540-45414-4_21

Cited by 300 publications

(364 citation statements)

References 8 publications

Supporting

Mentioning

358

Contrasting

Unclassified

Order By: Relevance

“…5. There are several solutions to this problem, e.g., [24], and the latest method introduced by Harris [25] is to use a deletion mark. This deletion mark is updated atomically together with the next pointer, see the definition of the union Link in Fig.…”

Section: The New Lock-free Algorithmmentioning

confidence: 99%

Lock-free deques and doubly linked lists

Sundell

Tsigas

2008

Journal of Parallel and Distributed Computing

View full text Add to dashboard Cite

a b s t r a c tWe present a practical lock-free shared data structure that efficiently implements the operations of a concurrent deque as well as a general doubly linked list. The implementation supports parallelism for disjoint accesses and uses atomic primitives which are available in modern computer systems. Previously known lock-free algorithms of doubly linked lists are either based on non-available atomic synchronization primitives, only implement a subset of the functionality, or are not designed for disjoint accesses. Our algorithm only requires single-word compare-and-swap atomic primitives, supports fully dynamic list sizes, and allows traversal also through deleted nodes and thus avoids unnecessary operation retries. We have performed an empirical study of our new algorithm on two different multiprocessor platforms. Results of the experiments performed under high contention show that the performance of our implementation scales linearly with increasing number of processors. Considering deque implementations and systems with low concurrency, the algorithm by Michael shows the best performance. However, as our algorithm is designed for disjoint accesses, it performs significantly better on systems with high concurrency and non-uniform memory architecture.

show abstract

Section: The New Lock-free Algorithmmentioning

confidence: 99%

Lock-free deques and doubly linked lists

Sundell

Tsigas

2008

Journal of Parallel and Distributed Computing

View full text Add to dashboard Cite

show abstract

“…These transitions are summarized in Figure 1. Finally, a thread can check whether a value v is injail by invoking IsInJail(v); if this invocation returns true, then v was injail at some point during the invocation 5 (the converse is not necessarily true, as explained later). An ROP solution does not implement the functionality of the Arrest action-this is application-specific-but ROP must be aware of arrests to know when a free value becomes injail.…”

Section: The Repeat Offender Problemmentioning

confidence: 99%

“…This definition precludes the use of locks to protect the data structure because a thread can take an unbounded number of steps without completing an operation if some other thread is delayed or fails while holding a lock that the first thread requires. The difficulty of designing lock-free data structures is reflected in numerous papers in the literature describing clever and subtle algorithms for implementing relatively mundane data structures such as stacks [13], queues [10], and linked lists [14,5].…”

Section: Introductionmentioning

confidence: 99%

The Repeat Offender Problem: A Mechanism for Supporting Dynamic-Sized, Lock-Free Data Structures

Herlihy

Luchangco

Moir

2002

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract:We define the Repeat Offender Problem (ROP). Elsewhere, we have presented the first dynamic-sized lock-free data structures that can free memory to any standard memory allocator-even after thread failures-without requiring special support from the operating system, the memory allocator, or the hardware. These results depend on a solution to the ROP problem. Here we present the first solution to the ROP problem and its correctness proof. Our solution is implementable in most modern shared memory multiprocessors.

show abstract

“…It is for instance impossible to use the remove and put operations of a hash table to obtain a concurrent move operation that can be used to rebalance the table after a resize [5]. Indeed, the difficulty of composing lock-free operations [6], [7] is a major limitation of the java.util.concurrent package [8] of the JDK. For example, the size method of the ConcurrentSkipListMap class is known to not be atomic, forcing the user to explicitly lock existing sequential data structures in a coarse-grained manner, which then severely hampers concurrency.…”

Section: Introductionmentioning

confidence: 99%

Composing Relaxed Transactions

Gramoli

Guerraoui

Leţia

2013

2013 IEEE 27th International Symposium on Parallel and Distributed Processing

View full text Add to dashboard Cite

Abstract-As the classic transactional abstraction is sometimes considered too restrictive in leveraging parallelism, a lot of work has been devoted to devising relaxed transactional models with the goal of improving concurrency. Nevertheless, the quest for improving concurrency has somehow led to neglect one of the most appealing aspects of transactions: software composition, namely, the ability to develop pieces of software independently and compose them into applications that behave correctly in the face of concurrency. Indeed, a closer look at relaxed transactional models reveals that they do jeopardize composition, raising the fundamental question whether it is at all possible to devise such models while preserving composition. This paper shows that the answer is positive.We present outheritance, a necessary and sufficient condition for a (potentially relaxed) transactional memory to support composition. Basically, outheritance requires child transactions to pass their conflict information to their parent transaction, which in turn maintains this information until commit time. Concrete instantiations of this idea have been used before, classic transactions being the most prevalent example, but we believe to be the first to capture this as a general principle as well as to prove that it is, strictly speaking, equivalent to ensuring composition.We illustrate the benefits of outheritance using elastic transactions and show how they can satisfy outheritance and provide composition without hampering concurrency. We leverage this to present a new (transactional) Java package, a composable alternative to the concurrency package of the JDK, and evaluate efficiency through an implementation that speeds up state of the art software transactional memory implementations (TL2, LSA, SwissTM) by almost a factor of 3.

show abstract

A Pragmatic Implementation of Non-blocking Linked-lists

Cited by 300 publications

References 8 publications

Lock-free deques and doubly linked lists

Lock-free deques and doubly linked lists

The Repeat Offender Problem: A Mechanism for Supporting Dynamic-Sized, Lock-Free Data Structures

Composing Relaxed Transactions

Contact Info

Product

Resources

About