Tentative steps toward a development method for interfering programs
ACM Transactions on Programming Languages and Systems (TOPLAS)
The existence of refinement mappings
Theoretical Computer Science
A Practical Multi-word Compare-and-Swap Operation
DISC '02 Proceedings of the 16th International Conference on Distributed Computing
Using Ghost Variables to Prove Refinement
AMAST '96 Proceedings of the 5th International Conference on Algebraic Methodology and Software Technology
CONCUR '02 Proceedings of the 13th International Conference on Concurrency Theory
Local rely-guarantee reasoning
Proceedings of the 36th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages
VSTTE'10 Proceedings of the Third international conference on Verified software: theories, tools, experiments
Making prophecies with decision predicates
Proceedings of the 38th annual ACM SIGPLAN-SIGACT symposium on Principles of programming languages
A marriage of rely/guarantee and separation logic
CONCUR'07 Proceedings of the 18th international conference on Concurrency Theory
Hi-index | 0.00 |
Verifying the implementation of concurrent objects essentially proves the fine-grained implementation of object methods refines the corresponding abstract atomic operations. To simplify the specifications and proofs, we usually need auxiliary history and prophecy variables to record historical events and to predict future events, respectively. Although the meaning of history variables is obvious, the semantics of prophecy variables and the corresponding auxiliary code is tricky and has never been clearly spelled out operationally. In this paper, we propose a new language construct, future blocks, that allows structural use of prophecy variables to refer to events in the future. The semantics of the construct is simple and easy to understand, without using any form of oracle or backward reasoning. Our language also separates auxiliary states from physical program states. With careful syntactic constraints, it ensures the use of history and prophecy variables would not affect the behaviors of the original program, which justifies the verification method based on the use of auxiliary variables.