500 research outputs found
Bridging the Gap between Programming Languages and Hardware Weak Memory Models
We develop a new intermediate weak memory model, IMM, as a way of
modularizing the proofs of correctness of compilation from concurrent
programming languages with weak memory consistency semantics to mainstream
multi-core architectures, such as POWER and ARM. We use IMM to prove the
correctness of compilation from the promising semantics of Kang et al. to POWER
(thereby correcting and improving their result) and ARMv7, as well as to the
recently revised ARMv8 model. Our results are mechanized in Coq, and to the
best of our knowledge, these are the first machine-verified compilation
correctness results for models that are weaker than x86-TSO
TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA
Memory consistency models (MCMs) which govern inter-module interactions in a
shared memory system, are a significant, yet often under-appreciated, aspect of
system design. MCMs are defined at the various layers of the hardware-software
stack, requiring thoroughly verified specifications, compilers, and
implementations at the interfaces between layers. Current verification
techniques evaluate segments of the system stack in isolation, such as proving
compiler mappings from a high-level language (HLL) to an ISA or proving
validity of a microarchitectural implementation of an ISA.
This paper makes a case for full-stack MCM verification and provides a
toolflow, TriCheck, capable of verifying that the HLL, compiler, ISA, and
implementation collectively uphold MCM requirements. The work showcases
TriCheck's ability to evaluate a proposed ISA MCM in order to ensure that each
layer and each mapping is correct and complete. Specifically, we apply TriCheck
to the open source RISC-V ISA, seeking to verify accurate, efficient, and legal
compilations from C11. We uncover under-specifications and potential
inefficiencies in the current RISC-V ISA documentation and identify possible
solutions for each. As an example, we find that a RISC-V-compliant
microarchitecture allows 144 outcomes forbidden by C11 to be observed out of
1,701 litmus tests examined. Overall, this paper demonstrates the necessity of
full-stack verification for detecting MCM-related bugs in the hardware-software
stack.Comment: Proceedings of the Twenty-Second International Conference on
Architectural Support for Programming Languages and Operating System
Formal Modelling, Testing and Verification of HSA Memory Models using Event-B
The HSA Foundation has produced the HSA Platform System Architecture
Specification that goes a long way towards addressing the need for a clear and
consistent method for specifying weakly consistent memory. HSA is specified in
a natural language which makes it open to multiple ambiguous interpretations
and could render bugs in implementations of it in hardware and software. In
this paper we present a formal model of HSA which can be used in the
development and verification of both concurrent software applications as well
as in the development and verification of the HSA-compliant platform itself. We
use the Event-B language to build a provably correct hierarchy of models from
the most abstract to a detailed refinement of HSA close to implementation
level. Our memory models are general in that they represent an arbitrary number
of masters, programs and instruction interleavings. We reason about such
general models using refinements. Using Rodin tool we are able to model and
verify an entire hierarchy of models using proofs to establish that each
refinement is correct. We define an automated validation method that allows us
to test baseline compliance of the model against a suite of published HSA
litmus tests. Once we complete model validation we develop a coverage driven
method to extract a richer set of tests from the Event-B model and a user
specified coverage model. These tests are used for extensive regression testing
of hardware and software systems. Our method of refinement based formal
modelling, baseline compliance testing of the model and coverage driven test
extraction using the single language of Event-B is a new way to address a key
challenge facing the design and verification of multi-core systems.Comment: 9 pages, 10 figure
Weak persistency semantics from the ground up: formalising the persistency semantics of ARMv8 and transactional models
Emerging non-volatile memory (NVM) technologies promise the durability of disks with the performance of volatile memory (RAM). To describe the persistency guarantees of NVM, several memory persistency models have been proposed in the literature. However, the formal persistency semantics of mainstream hardware is unexplored to date. To close this gap, we present a formal declarative framework for describing concurrency models in the NVM context, and then develop the PARMv8 persistency model as an instance of our framework, formalising the persistency semantics of the ARMv8 architecture for the first time. To facilitate correct persistent programming, we study transactions as a simple abstraction for concurrency and persistency control. We thus develop the PSER (persistent serialisability) persistency model, formalising transactional semantics in the NVM context for the first time, and demonstrate that PSER correctly compiles to PARMv8. This then enables programmers to write correct, concurrent and persistent programs, without having to understand the low-level architecture-specific persistency semantics of the underlying hardware
GPU Concurrency: Weak Behaviours and Programming Assumptions
Concurrency is pervasive and perplexing, particularly on graphics processing units (GPUs). Current specifications of languages and hardware are inconclusive; thus programmers often rely on folklore assumptions when writing software.
To remedy this state of affairs, we conducted a large empirical study of the concurrent behaviour of deployed GPUs. Armed with litmus tests (i.e. short concurrent programs), we questioned the assumptions in programming guides and vendor documentation about the guarantees provided by hardware. We developed a tool to generate thousands of litmus tests and run them under stressful workloads. We observed a litany of previously elusive weak behaviours, and exposed folklore beliefs about GPU programming---often supported by official tutorials---as false.
As a way forward, we propose a model of Nvidia GPU hardware, which correctly models every behaviour witnessed in our experiments. The model is a variant of SPARC Relaxed Memory Order (RMO), structured following the GPU concurrency hierarchy
Robustness against Power is PSPACE-complete
Power is a RISC architecture developed by IBM, Freescale, and several other
companies and implemented in a series of POWER processors. The architecture
features a relaxed memory model providing very weak guarantees with respect to
the ordering and atomicity of memory accesses.
Due to these weaknesses, some programs that are correct under sequential
consistency (SC) show undesirable effects when run under Power. We call these
programs not robust against the Power memory model. Formally, a program is
robust if every computation under Power has the same data and control
dependencies as some SC computation.
Our contribution is a decision procedure for robustness of concurrent
programs against the Power memory model. It is based on three ideas. First, we
reformulate robustness in terms of the acyclicity of a happens-before relation.
Second, we prove that among the computations with cyclic happens-before
relation there is one in a certain normal form. Finally, we reduce the
existence of such a normal-form computation to a language emptiness problem.
Altogether, this yields a PSPACE algorithm for checking robustness against
Power. We complement it by a matching lower bound to show PSPACE-completeness
- …