269 research outputs found
Events in Property Patterns
A pattern-based approach to the presentation, codification and reuse of
property specifications for finite-state verification was proposed by Dwyer and
his collegues. The patterns enable non-experts to read and write formal
specifications for realistic systems and facilitate easy conversion of
specifications between formalisms, such as LTL, CTL, QRE. In this paper, we
extend the pattern system with events - changes of values of variables in the
context of LTL.Comment: 14 pages, 3 figure
Consensus on Transaction Commit
The distributed transaction commit problem requires reaching agreement on
whether a transaction is committed or aborted. The classic Two-Phase Commit
protocol blocks if the coordinator fails. Fault-tolerant consensus algorithms
also reach agreement, but do not block whenever any majority of the processes
are working. Running a Paxos consensus algorithm on the commit/abort decision
of each participant yields a transaction commit protocol that uses 2F +1
coordinators and makes progress if at least F +1 of them are working. In the
fault-free case, this algorithm requires one extra message delay but has the
same stable-storage write delay as Two-Phase Commit. The classic Two-Phase
Commit algorithm is obtained as the special F = 0 case of the general Paxos
Commit algorithm.Comment: Original at
http://research.microsoft.com/research/pubs/view.aspx?tr_id=70
TLA+ Proofs
TLA+ is a specification language based on standard set theory and temporal
logic that has constructs for hierarchical proofs. We describe how to write
TLA+ proofs and check them with TLAPS, the TLA+ Proof System. We use Peterson's
mutual exclusion algorithm as a simple example to describe the features of
TLAPS and show how it and the Toolbox (an IDE for TLA+) help users to manage
large, complex proofs.Comment: A shorter version of this article appeared in the proceedings of the
conference Formal Methods 2012 (FM 2012, Paris, France, Springer LNCS 7436,
pp. 147-154
The existence of refinement mappings
AbstractRefinement mappings are used to prove that a lower-level specification correctly implements a higher-level one. We consider specifications consisting of a state machine (which may be infinite- state) that specifies safety requirements, and an arbitrary supplementary property that specifies liveness requirements. A refinement mapping from a lower-level specification S1 to a higher-level one S2 is a mapping from S1's state space to S2's state space. It maps steps of S1's state machine to steps of S2's state machine and maps behaviors allowed by S1 to behaviors allowed by S2. We show that, under reasonable assumptions about the specification, if S1 implements S2, then by adding auxiliary variables to S1 we can guarantee the existence of a refinement mapping. This provides a completeness result for a practical, hierarchical specification method
How to Make a Correct Multiprocess Program Execute Correctly on a Multiprocessor
Abstract A multiprocess program executing on a modern multiprocessor must issue explicit commands to synchronize memory accesses. A method is proposed for deriving the necessary commands from a correctness proof of the underlying algorithm in a formalism based on temporal relations among operation executions
Auxiliary Variables in TLA+
Auxiliary variables are often needed for verifying that an implementation is correct with respect to a higher-level specification. They augment the formal description of the implementation without changing its semanticsâthat is, the set of behaviors that it describes. This paper explains rules for adding history, prophecy, and stuttering variables to TLA+ specifications, ensuring that the augmented specification is equivalent to the original one. The rules are explained with toy examples, and they are used to verify the correctness of a simplified version of a snapshot algorithm due to Afek et al
Prophecy Made Simple
International audienceProphecy variables were introduced in the article âThe Existence of Refinement Mappingsâ by Abadi and Lamport. They were difficult to use in practice. We describe a new kind of prophecy variable that we find much easier to use. We also reformulate ideas from that article in a more mathematical way
DĂ©finitions rĂ©cursives dâopĂ©rateurs
TLA+ originally allowed recursive function definitions, but not recursive operator definitions, because it was not known how how to define their semantics. They were added to the language in 2006 after we discovered a semantics for them. We describe that semantics here.Initialement, TLA+ autorisait les dĂ©finitions rĂ©cursives de fonctions, mais pas dâopĂ©rateurs, car la sĂ©mantique Ă donner Ă de telles dĂ©finitions nâĂ©tait pas claire. Elles furent finalement ajoutĂ©es au langage de spĂ©cification en 2006, lorsque nous avons dĂ©couvert un moyen de leur donner une sĂ©mantique satisfaisante. Ce rapport dĂ©crit cette sĂ©mantique
- âŠ