Results 1  10
of
217
Linearizability: a correctness condition for concurrent objects
, 1990
"... A concurrent object is a data object shared by concurrent processes. Linearizability is a correctness condition for concurrent objects that exploits the semantics of abstract data types. It permits a high degree of concurrency, yet it permits programmers to specify and reason about concurrent object ..."
Abstract

Cited by 1178 (28 self)
 Add to MetaCart
(Show Context)
A concurrent object is a data object shared by concurrent processes. Linearizability is a correctness condition for concurrent objects that exploits the semantics of abstract data types. It permits a high degree of concurrency, yet it permits programmers to specify and reason about concurrent objects using known techniques from the sequential domain. Linearizability provides the illusion that each operation applied by concurrent processes takes effect instantaneously at some point between its invocation and its response, implying that the meaning of a concurrent object’s operations can be given by pre and postconditions. This paper defines linearizability, compares it to other correctness conditions, presents and demonstrates a method for proving the correctness of implementations, and shows how to reason about concurrent objects, given they are linearizable.
WaitFree Synchronization
 ACM Transactions on Programming Languages and Systems
, 1993
"... A waitfree implementation of a concurrent data object is one that guarantees that any process can complete any operation in a finite number of steps, regardless of the execution speeds of the other processes. The problem of constructing a waitfree implementation of one data object from another lie ..."
Abstract

Cited by 851 (28 self)
 Add to MetaCart
(Show Context)
A waitfree implementation of a concurrent data object is one that guarantees that any process can complete any operation in a finite number of steps, regardless of the execution speeds of the other processes. The problem of constructing a waitfree implementation of one data object from another lies at the heart of much recent work in concurrent algorithms, concurrent data structures, and multiprocessor architectures. In the first part of this paper, we introduce a simple and general technique, based on reduction to a consensus protocol, for proving statements of the form "there is no waitfree implementation of X by Y ." We derive a hierarchy of objects such that no object at one level has a waitfree implementation in terms of objects at lower levels. In particular, we show that atomic read/write registers, which have been the focus of much recent attention, are at the bottom of the hierarchy: they cannot be used to construct waitfree implementations of many simple and familiar da...
Composing Specifications
 ACM TRANSACTIONS ON PROGRAMMING LANGUAGES AND SYSTEMS
, 1993
"... ..."
(Show Context)
Hierarchical correctness proofs for distributed algorithms
, 1987
"... We introduce the inputoutput automaton, a simple but powerful model of computation in asynchronous distributed networks. With this model we are able to construct modular, hierarchical correctness proofs for distributed algorithms. We define this model, and give an interesting example of how it can ..."
Abstract

Cited by 418 (51 self)
 Add to MetaCart
We introduce the inputoutput automaton, a simple but powerful model of computation in asynchronous distributed networks. With this model we are able to construct modular, hierarchical correctness proofs for distributed algorithms. We define this model, and give an interesting example of how it can be used to construct such proofs.
A Methodology for Implementing Highly Concurrent Data Objects
, 1993
"... A concurrent object is a data structure shared by concurrent processes. Conventional techniques for implementing concurrent objects typically rely on critical sections: ensuring that only one process at a time can operate on the object. Nevertheless, critical sections are poorly suited for asynchro ..."
Abstract

Cited by 350 (10 self)
 Add to MetaCart
(Show Context)
A concurrent object is a data structure shared by concurrent processes. Conventional techniques for implementing concurrent objects typically rely on critical sections: ensuring that only one process at a time can operate on the object. Nevertheless, critical sections are poorly suited for asynchronous systems: if one process is halted or delayed in a critical section, other, nonfaulty processes will be unable to progress. By contrast, a concurrent object implementation is lock free if it always guarantees that some process will complete an operation in a finite number of steps, and it is wait free if it guarantees that each process will complete an operation in a finite number of steps. This paper proposes a new methodology for constructing lockfree and waitfree implementations of concurrent objects. The object’s representation and operations are written as stylized sequential programs, with no explicit synchronization. Each sequential operation is automatically transformed into a lockfree or waitfree operation using novel synchronization and memory management algorithms. These algorithms are presented for a multiple instruction/multiple data (MIMD) architecture in which n processes communicate by applying atomic read, wrzte, load_linked, and store_conditional operations to a shared memory.
A Simple Approach to Specifying Concurrent Systems
, 1988
"... In the transition axiom method, safety properties of a concurrent system can be specified by programs; liveness properties are specified by assertions in a simple temporal logic. The method is described with some simple examples, and its logical foundation is informally explored through a careful ex ..."
Abstract

Cited by 132 (7 self)
 Add to MetaCart
In the transition axiom method, safety properties of a concurrent system can be specified by programs; liveness properties are specified by assertions in a simple temporal logic. The method is described with some simple examples, and its logical foundation is informally explored through a careful examination of what it means to implement a specification. Language issues and other practical details are largely ignored.
You Assume, We Guarantee: Methodology and Case Studies
, 1998
"... Assumeguarantee reasoning has long been advertised as an important method for decomposing proof obligations in system verification. Re nement mappings (homomorphisms) have long been advertised as an important method for solving the languageinclusion problem in practice. When confronted with large ..."
Abstract

Cited by 119 (18 self)
 Add to MetaCart
Assumeguarantee reasoning has long been advertised as an important method for decomposing proof obligations in system verification. Re nement mappings (homomorphisms) have long been advertised as an important method for solving the languageinclusion problem in practice. When confronted with large verification problems, we therefore attempted to make use of both techniques. We soon found that rather than o ering instant solutions, the success of assumeguarantee reasoning depends critically on the construction of suitable abstraction modules, and the success of refinement checking depends critically on the construction of suitable witness modules. Moreover, as abstractions need to be witnessed, and witnesses abstracted, the process must be iterated. We present here the main lessons we learned from our experiments, in form of a systematic and structured discipline for the compositional verification of reactive modules. An infrastructure to support this discipline, and automate parts of the verification, has been implemented in the tool Mocha.