Are you Luc Maranget?

Claim your profile

Publications (12)1.69 Total impact

  • [Show abstract] [Hide abstract]
    ABSTRACT: We propose an axiomatic generic framework for modelling weak memory. We show how to instantiate this framework for SC, TSO, C++ restricted to release-acquire atomics, and Power. For Power, we compare our model to a preceding operational model in which we found a flaw. To do so, we define an operational model that we show equivalent to our axiomatic model. We also propose a model for ARM. Our testing on this architecture revealed a behaviour later acknowledged as a bug by ARM, and more recently 33 additional anomalies. We offer a new simulation tool, called herd, which allows the user to specify the model of his choice in a concise way. Given a specification of a model, the tool becomes a simulator for that model. The tool relies on an axiomatic description; this choice allows us to outperform all previous simulation tools. Additionally, we confirm that verification time is vastly improved, in the case of bounded model-checking. Finally, we put our models in perspective, in the light of empirical data obtained by analysing the C and C++ code of a Debian Linux distribution. We present our new analysis tool, called mole, which explores a piece of code to find the weak memory idioms that it uses.
    ACM SIGPLAN Notices 08/2013; 49(6). · 0.71 Impact Factor
  • [Show abstract] [Hide abstract]
    ABSTRACT: The growing complexity of hardware optimizations employed by multiprocessors leads to subtle distinctions among allowed and disallowed behaviors, posing challenges in specifying their memory models formally and accurately, and in understanding and analyzing the behavior of concurrent software. This complexity is particularly evident in the IBM® Power Architecture®, for which a faithful specification was published only in 2011 using an operational style. In this paper we present an equivalent axiomatic specification, which is more abstract and concise. Although not officially sanctioned by the vendor, our results indicate that this axiomatic specification provides a reasonable basis for reasoning about current IBM® POWER® multiprocessors. We establish the equivalence of the axiomatic and operational specifications using both manual proof and extensive testing. To demonstrate that the constraint-based style of axiomatic specification is more amenable to computer-aided verification, we develop a SAT-based tool for evaluating possible outcomes of multi-threaded test programs, and we show that this tool is significantly more efficient than a tool based on an operational specification.
    Proceedings of the 24th international conference on Computer Aided Verification; 07/2012
  • [Show abstract] [Hide abstract]
    ABSTRACT: We present a class of relaxed memory models, defined in Coq, parameterised by the chosen permitted local reorderings of reads and writes, and by the visibility of inter- and intra-processor communications through memory (e.g. store atomicity relaxation). We prove results on the required behaviour and placement of memory fences to restore a given model (such as Sequential Consistency) from a weaker one. Based on this class of models we develop a tool, diy, that systematically and automatically generates and runs litmus tests. These tests can be used to explore the behaviour of processor implementations and the behaviour of models, and hence to compare the two against each other. We detail the results of experiments on Power and a model we base on them.
    Formal Methods in System Design 04/2012; 40(2). · 0.28 Impact Factor
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Shared memory concurrency relies on synchronisation primitives: compare-and-swap, load-reserve/store-conditional (aka LL/SC), language-level mutexes, and so on. In a sequentially consistent setting, or even in the TSO setting of x86 and Sparc, these have well-understood semantics. But in the very relaxed settings of IBM®, POWER®, ARM, or C/C++, it remains surprisingly unclear exactly what the programmer can depend on. This paper studies relaxed-memory synchronisation. On the hardware side, we give a clear semantic characterisation of the load-reserve/store-conditional primitives as provided by POWER multiprocessors, for the first time since they were introduced 20 years ago; we cover their interaction with relaxed loads, stores, barriers, and dependencies. Our model, while not officially sanctioned by the vendor, is validated by extensive testing, comparing actual implementation behaviour against an oracle generated from the model, and by detailed discussion with IBM staff. We believe the ARM semantics to be similar. On the software side, we prove sound a proposed compilation scheme of the C/C++ synchronisation constructs to POWER, including C/C++ spinlock mutexes, fences, and read-modify-write operations, together with the simpler atomic operations for which soundness is already known from our previous work; this is a first step in verifying concurrent algorithms that use load-reserve/store-conditional with respect to a realistic semantics. We also build confidence in the C/C++ model in its own terms, fixing some omissions and contributing to the C standards committee adoption of the C++11 concurrency model.
    01/2012;
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Exploiting today's multiprocessors requires high-performance and correct concurrent systems code (optimising compilers, language runtimes, OS kernels, etc.), which in turn requires a good understanding of the observable processor behaviour that can be relied on. Unfortunately this critical hardware/software interface is not at all clear for several current multiprocessors. In this paper we characterise the behaviour of IBM POWER multiprocessors, which have a subtle and highly relaxed memory model (ARM multiprocessors have a very similar architecture in this respect). We have conducted extensive experiments on several generations of processors: POWER G5, 5, 6, and 7. Based on these, on published details of the microarchitectures, and on discussions with IBM staff, we give an abstract-machine semantics that abstracts from most of the implementation detail but explains the behaviour of a range of subtle examples. Our semantics is explained in prose but defined in rigorous machine-processed mathematics; we also confirm that it captures the observable processor behaviour, or the architectural intent, for our examples with an executable checker. While not officially sanctioned by the vendor, we believe that this model gives a reasonable basis for reasoning about current POWER multiprocessors. Our work should bring new clarity to concurrent systems programming for these architectures, and is a necessary precondition for any analysis or verification. It should also inform the design of languages such as C and C++, where the language memory model is constrained by what can be efficiently compiled to such multiprocessors.
    Proceedings of the 32nd ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI 2011, San Jose, CA, USA, June 4-8, 2011; 01/2011
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Shared memory multiprocessors typically expose subtle, poorly understood and poorly specified relaxed-memory semantics to programmers. To understand them, and to develop formal models to use in program verification, we find it essential to take an empirical approach, testing what results parallel programs can actually produce when executed on the hardware. We describe a key ingredient of our approach, our litmus tool, which takes small ‘litmus test’ programs and runs them for many iterations to find interesting behaviour. It embodies various techniques for making such interesting behaviour appear more frequently.
    Tools and Algorithms for the Construction and Analysis of Systems - 17th International Conference, TACAS 2011, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2011, Saarbrücken, Germany, March 26-April 3, 2011. Proceedings; 01/2011
  • Jade Alglave, Luc Maranget
    [Show abstract] [Hide abstract]
    ABSTRACT: Concurrent programs running on weak memory models exhibit relaxed behaviours, making them hard to understand and to debug. To use standard verification techniques on such programs, we can force them to behave as if running on a Sequentially Consistent (SC) model. Thus, we examine how to constrain the behaviour of such programs via synchronisation to ensure what we call their stability, i.e. that they behave as if they were running on a stronger model than the actual one, e.g. SC. First, we define sufficient conditions ensuring stability to a program, and show that Power’s locks and read-modify-write primitives meet them. Second, we minimise the amount of required synchronisation by characterising which parts of a given execution should be synchronised. Third, we characterise the programs stable from a weak architecture to SC. Finally, we present our offence tool which places either lock-based or lock-free synchronisation in a x86 or Power program to ensure its stability.
    Computer Aided Verification - 23rd International Conference, CAV 2011, Snowbird, UT, USA, July 14-20, 2011. Proceedings; 01/2011
  • Source
    Alglave Jade, Luc Maranget
    [Show abstract] [Hide abstract]
    ABSTRACT: We present here an axiomatic framework, implemented in the Coq proof assistant, for defining weak memory models in terms of several parameters: local reorderings of reads and writes, and visibility of inter and intra processor communications through memory. In this context, we provide formal definition of weak memory models induced by architectures, illustrated by definitions of SC and Sparc TSO. Moreover, we define a comparison over architectures, an architecture A1 being weaker than another one A2 when A1 allows more behaviours than A2. In addition, we provide a characterisation of behaviours allowed by A1 which are also valid on A2. By that means, we provide a simple characterisation of SC and TSO behaviours on any weaker architecture. We also provide an abstract notion of what should be the action and placement of fences to restore a given model from a weaker one. Our framework led us to a model of a significant fragment of PowerPC with fences. In the absence of any public formal model of PowerPC, we base our study on intensive testing. We illustrate our approach by providing several tests that highlight the parameters of our model.
    01/2010;
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: We present a class of relaxed memory models, defined in Coq, parameterised by the chosen permitted local reorderings of reads and writes, and the visibility of inter- and intra-processor communications through memory (e.g. store atomicity relaxation) We prove results on the required behaviour and placement of memory fences to restore a given model (such as Sequential Consistency) from a weaker one Based on this class of models we develop a tool, diy, that systematically and automatically generates and runs litmus tests to determine properties of processor implementations We detail the results of our experiments on Power and the model we base on them This work identified a rare implementation error in Power 5 memory barriers (for which IBM is providing a workaround); our results also suggest that Power 6 does not suffer from this problem.
    Computer Aided Verification, 22nd International Conference, CAV 2010, Edinburgh, UK, July 15-19, 2010. Proceedings; 01/2010
  • Jade Alglave, Luc Maranget
    [Show abstract] [Hide abstract]
    ABSTRACT: Concurrent programs running on weak memory models ex-hibit relaxed behaviours, making them hard to understand and to debug. We examine how to constrain the behaviour of such programs via syn-chronisation to ensure what we call their stability, i.e. that they behave as if they were running on a stronger model than the actual one, for ex-ample Sequential Consistency (SC). First, we define sufficient conditions ensuring stability to a program, and show that Power's locks and read-modify-write primitives meet them. Second, we minimise the amount of required synchronisation by characterising which parts of a given execu-tion should be synchronised. Third, we characterise the programs stable from a weak architecture to SC. Finally, we present the offence tool im-plementing our approach, by placing either lock-based or lock-free syn-chronisation in a x86 or Power program to ensure its stability. Concurrent programs running on modern multiprocessors exhibit subtle be-haviours, making them hard to understand and to debug: modern architectures (e.g. x86 or Power) provide weak memory models, allowing optimisations such as instruction reordering, store buffering or write atomicity relaxation [2]. Thus an execution of a program may not be an interleaving of its instructions, as it would be on a Sequentially Consistent (SC) architecture [17]. Hence standard analyses for concurrent programs might be unsound, as noted by M. Rinard in [21]. There exist a few memory model aware verification tools [11, 15, 20, 26], but they often focus on one model at a time, or cannot handle the write atomicity relaxation exhibited for example by Power: generality remains a challenge. Fortunately, we can force a program running on a weak architecture to behave as if it were running on a stronger one (e.g. SC) by using synchronisation prim-itives. Hence, as observed by S. Burckhart and M. Musuvathi in [12], "we can sensibly verify the relaxed executions [. . . ] by solving the following two verifica-tion problems separately: 1. Use standard verification methodology for concurrent programs to show that the [SC] executions [. . . ] are correct. 2. Use specialized methodology for memory model safety verification [. . . ]". Here, memory model safety means checking that the executions of a program, although running on a weak architecture, are actually SC. To apply standard verification techniques to concurrent programs running on weak memory models, we thus first need to ensure that our programs have a SC behaviour. S. Burckhart and M. Musuvathi focus in [12] on memory model safety for TSO [24]. We generalise their idea to a wider class of models (the one defined in [5], and recalled in Sec. 1): we examine how to force a program running on a weak architecture A 1 to behave as if running on a stronger one A 2 , a property that we call stability from A 1 to A 2 .
  • Source
    Jade Alglave, Luc Maranget
    [Show abstract] [Hide abstract]
    ABSTRACT: We present an axiomatic framework, implemented in the Coq proof assistant, to define weak memory models in terms of several parameters: local reorderings of reads and writes, and visibility of inter and intra processor communications through memory, including full store atomicity relaxation. Thereby, we give a formal hierarchy of weak memory models, in which we provide a formal study of what should be the action and placement of fences to restore a given model such as SC from a weaker one. Finally, we provide formal requirements for abstract locks that guarantee SC semantics to data race free programs, and show that a particular implementation of locks matches these requirements.
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: Multiprocessors and high-level languages generally provide only relaxed (non-sequentially-consistent) memory models, to permit performance optimisations. One has to understand these models to program reliable concurrent systems — but they are typically ambiguous and incomplete informal-prose documents, sometimes give guarantees that are too weak to be useful, and are sometimes simply unsound. Based on our previous work, we review various problems with some current specifications, for x86 (Intel 64/IA32 and AMD64), and Power and ARM processors, and for the Java and C++ languages. We argue that such specifications should be rigorously defined and tested.