Protocol Verification via Projections

Lam, Simon S.; Shankar, A. Udaya

doi:10.1109/tse.1984.5010246

Cited by 184 publications

(38 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…By pitfalls, we mean subtle aspects of a formalism that can lead unwary users to write specifications that don't mean what the users think they do. We illustrate some pitfalls using an action formalism, in which a system is specified by an initial predicate and a next-state relation, which is a predicate relating old and new values [Hehner 1984;Lam and Shankar 1984]. For example, a nonterminating program in which n is initially 0 and is continually decremented by 1 is specified by the initial predicate n = 0 and the next-state relation n = n − 1.…”

Section: Conveniencementioning

confidence: 99%

Should your specification language be typed

Lamport¹,

Paulson

1999

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

Most specification languages have a type system. Type systems are hard to get right, and getting them wrong can lead to inconsistencies. Set theory can serve as the basis for a specification language without types. This possibility, which has been widely overlooked, offers many advantages. Untyped set theory is simple and is more flexible than any simple typed formalism. Polymorphism, overloading, and subtyping can make a type system more powerful, but at the cost of increased complexity, and such refinements can never attain the flexibility of having no types at all. Typed formalisms have advantages too, stemming from the power of mechanical type checking. While types serve little purpose in hand proofs, they do help with mechanized proofs. In the absence of verification, type checking can catch errors in specifications. It may be possible to have the best of both worlds by adding typing annotations to an untyped specification language.We consider only specification languages, not programming languages.

show abstract

Section: Conveniencementioning

confidence: 99%

Should your specification language be typed

Lamport¹,

Paulson

1999

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

show abstract

“…The idea of using abstraction functions to relate implementation and specification state graphs is very widely used, especially when manual or automatic theorem-proving is used [30], [29], [22] (indeed, whole volumes have been written on the subject [8]). The idea has also been used with finite-state techniques [19], [11].…”

Section: Abstraction Functionmentioning

confidence: 99%

Verification of Cache Coherence Protocols by Aggregation of Distributed Transactions

Park

Dill

1998

Theory of Computing Systems

View full text Add to dashboard Cite

Abstract. This paper presents a method to verify the correctness of protocols and distributed algorithms. The method compares a state graph of the implementation with a specification which is a state graph representing the desired abstract behavior. The steps in the specification correspond to atomic transactions, which are not atomic in the implementation.The method relies on an aggregation function, which is a type of abstraction function that aggregates the steps of each transaction in the implementation into a single atomic transaction in the specification. The key idea in defining the aggregation function is that it must complete atomic transactions which have committed but are not finished. This paper illustrates the method on a directory-based cache coherence protocol developed for the Stanford FLASH multiprocessor. The coherence protocol consisting of more than a hundred different kinds of implementation steps has been reduced to a specification with six kinds of atomic transactions. Based on the reduced behavior, it is very easy to prove crucial properties of the protocol including data consistency of cached copies at the user level. This is the first correctness proof verified by a theorem-prover for a cache coherence protocol of this complexity. The aggregation method is also used to prove that the reduced protocol satisfies a desired memory consistency model.

show abstract

“…B satisfies more properties than A. With state machines or I/O automata, a specification B may be considered as an implementation of the specification A iff there is an appropriate mapping from B to A [22,18,19,23,1,24]. With modal transition systems (i.e.…”

Section: Validity As a Non Necessarily Symmetric Relationmentioning

confidence: 99%

A framework based on implementation relations for implementing LOTOS specifications

Leduc

1992

Computer Networks and ISDN Systems

View full text Add to dashboard Cite

A framework is developed for studying the implementation process, as a stepwise process in which an abstract specification is successively transformed to reach a final compilable specification adapted to the computer environment. In this context, an implementation relation is referred to as the relation which should link any "valid" implementation to its abstract formal specification. In other words, the implementation relation is intended to express formally the notion of validity. Our framework allows the exact characterization of the transformations which may take place at each step for a given implementation relation. This framework is essential for dealing with non-transitive implementation relations. In the second part of the paper, these results are exemplified in LOTOS on some existing relations, and an apparent paradox is presented. Some new results about these relations are also derived.

show abstract

Protocol Verification via Projections

Cited by 184 publications

References 10 publications

Should your specification language be typed

Should your specification language be typed

Verification of Cache Coherence Protocols by Aggregation of Distributed Transactions

A framework based on implementation relations for implementing LOTOS specifications

Contact Info

Product

Resources

About