17,393 research outputs found
Automated Verification of Practical Garbage Collectors
Garbage collectors are notoriously hard to verify, due to their low-level
interaction with the underlying system and the general difficulty in reasoning
about reachability in graphs. Several papers have presented verified
collectors, but either the proofs were hand-written or the collectors were too
simplistic to use on practical applications. In this work, we present two
mechanically verified garbage collectors, both practical enough to use for
real-world C# benchmarks. The collectors and their associated allocators
consist of x86 assembly language instructions and macro instructions, annotated
with preconditions, postconditions, invariants, and assertions. We used the
Boogie verification generator and the Z3 automated theorem prover to verify
this assembly language code mechanically. We provide measurements comparing the
performance of the verified collector with that of the standard Bartok
collectors on off-the-shelf C# benchmarks, demonstrating their competitiveness
Verification of Shared-Reading Synchronisers
Synchronisation classes are an important building block for shared memory
concurrent programs. Thus to reason about such programs, it is important to be
able to verify the implementation of these synchronisation classes, considering
atomic operations as the synchronisation primitives on which the
implementations are built. For synchronisation classes controlling exclusive
access to a shared resource, such as locks, a technique has been proposed to
reason about their behaviour. This paper proposes a technique to verify
implementations of both exclusive access and shared-reading synchronisers. We
use permission-based Separation Logic to describe the behaviour of the main
atomic operations, and the basis for our technique is formed by a specification
for class AtomicInteger, which is commonly used to implement synchronisation
classes in java.util.concurrent. To demonstrate the applicability of our
approach, we mechanically verify the implementation of various synchronisation
classes like Semaphore, CountDownLatch and Lock.Comment: In Proceedings MeTRiD 2018, arXiv:1806.0933
Report on the formal specification and partial verification of the VIPER microprocessor
The formal specification and partial verification of the VIPER microprocessor is reviewed. The VIPER microprocessor was designed by RSRE, Malvern, England, for safety critical computing applications (e.g., aircraft, reactor control, medical instruments, armaments). The VIPER was carefully specified and partially verified in an attempt to provide a microprocessor with completely predictable operating characteristics. The specification of VIPER is divided into several levels of abstraction, from a gate-level description up to an instruction execution model. Although the consistency between certain levels was demonstrated with mechanically-assisted mathematical proof, the formal verification of VIPER was never completed
Subclassing errors, OOP, and practically checkable rules to prevent them
This paper considers an example of Object-Oriented Programming (OOP) leading
to subtle errors that break separation of interface and implementations. A
comprehensive principle that guards against such errors is undecidable. The
paper introduces a set of mechanically verifiable rules that prevent these
insidious problems. Although the rules seem restrictive, they are powerful and
expressive, as we show on several familiar examples. The rules contradict both
the spirit and the letter of the OOP. The present examples as well as available
theoretical and experimental results pose a question if OOP is conducive to
software development at all.Comment: 10 pages, 1 LaTeX file; accompanying C++ and Haskell code and
compilation instruction
Decreasing Duration of Mechanical Restraint Episodes by Increasing Registered Nurse Assessment and Surveillance in an Acute Psychiatric Hospital
Background
Application of mechanical restraints is a high-risk emergency measure that requires psychiatric intensive care in order to assure patient safety and expedite release at the earliest opportunity. While current regulations require that trained staff continuously observe restrained individuals, assessment by a registered nurse is required only once an hour. This project builds on research that demonstrated a regulatory change requiring more frequent registered nurse assessments led to decreased duration of mechanical restraint episodes in an acute psychiatric hospital.
Purpose
The purpose of this project was to implement and evaluate a practice change that required increased frequency of registered nurse assessment and surveillance during mechanical restraint episodes.
Methods
The nursing department standard requirement for frequency of face-to-face registered nurse assessment and surveillance of patients during episodes of mechanical restraint was increased on pilot units from once every thirty minutes to continuous assessment and surveillance throughout the duration of the restraint application. Quantitative data was collected on hours of duration of restraint episodes on four pilot units for three months before and three months after the intervention and mean duration of episodes was compared before and after the practice change.
Results
Mean duration of episodes on pilot units decreased 44% in the three months post intervention: 15% on adult units and 70% on the adolescent unit.
Conclusion and Recommendation
Increasing the frequency of registered nurse assessment and surveillance during mechanical restraint has been shown to decrease duration of restraint episodes. Nurses are encouraged to change practice standards for mechanical restraint, which is a high-risk emergency measure, to provide continuous psychiatric intensive care by a registered nurse.
Keywords: mechanical restraint, physical restraint, psychiatric patient
Renaming Global Variables in C Mechanically Proved Correct
Most integrated development environments are shipped with refactoring tools.
However, their refactoring operations are often known to be unreliable. As a
consequence, developers have to test their code after applying an automatic
refactoring. In this article, we consider a refactoring operation (renaming of
global variables in C), and we prove that its core implementation preserves the
set of possible behaviors of transformed programs. That proof of correctness
relies on the operational semantics of C provided by CompCert C in Coq.Comment: In Proceedings VPT 2016, arXiv:1607.0183
- …