657 research outputs found

    The weakest failure detectors to boost obstruction-freedom

    Get PDF
    It is considered good practice in concurrent computing to devise shared object implementations that ensure a minimal obstruction-free progress property and delegate the task of boosting liveness to independent generic oracles called contention managers. This paper determines necessary and sufficient conditions to implement wait-free and non-blocking contention managers, i.e., contention managers that ensure wait-freedom (resp. non-blockingness) of any associated obstruction-free object implementation. The necessary conditions hold even when universal objects (like compare-and-swap) or random oracles are available in the implementation of the contention manager. On the other hand, the sufficient conditions assume only basic read/write objects, i.e., registers. We show that failure detector \lozenge{\fancyscript{P}} is the weakest to convert any obstruction-free algorithm into a wait-free one, and Ω *, a new failure detector which we introduce in this paper, and which is strictly weaker than \lozenge\fancyscript{P} but strictly stronger than Ω, is the weakest to convert any obstruction-free algorithm into a non-blocking one. We also address the issue of minimizing the overhead imposed by contention management in low contention scenarios. We propose two intermittent failure detectors IΩ∗I_{\Omega^*} and I_{\lozenge\fancyscript{P}} that are in a precise sense equivalent to, respectively, Ω * and \lozenge\fancyscript{P} , but allow for reducing the cost of failure detection in eventually synchronous systems when there is little contention. We present two contention managers: a non-blocking one and a wait-free one, that use, respectively, IΩ∗I_{\Omega^*} and I_{\lozenge\fancyscript{P}} . When there is no contention, the first induces very little overhead whereas the second induces some non-trivial overhead. We show that wait-free contention managers, unlike their non-blocking counterparts, impose an inherent non-trivial overhead even in contention-free execution

    Improving the interoperability between MPI and task-based programming models

    Get PDF
    In this paper we propose an API to pause and resume task execution depending on external events. We leverage this generic API to improve the interoperability between MPI synchronous communication primitives and tasks. When an MPI operation blocks, the task running is paused so that the runtime system can schedule a new task on the core that became idle. Once the MPI operation is completed, the paused task is put again on the runtime system's ready queue. We expose our proposal through a new MPI threading level which we implement through two approaches. The first approach is an MPI wrapper library that works with any MPI implementation by intercepting MPI synchronous calls, implementing them on top of their asynchronous counterparts. In this case, the task-based runtime system is also extended to periodically check for pending MPI operations and resume the corresponding tasks once MPI operations complete. The second approach consists in directly modifying the MPICH runtime system, a well-known implementation of MPI, to directly call the pause/resume API when a synchronous MPI operation blocks and completes, respectively. Our experiments reveal that this proposal not only simplifies the development of hybrid MPI+OpenMP applications that naturally overlap computation and communication phases; it also improves application performance and scalability by removing artificial dependencies across communication tasks.This work has been developed with the support of the European Union Horizon 2020 Programme through both the INTERTWinE project (agreement No. 671602) and the Marie Sk lodowska-Curie grant (agreement No. 749516); the Spanish Government through the Severo Ochoa Program (SEV-2015-0493); the Spanish Ministry of Science and Innovation (TIN2015-65316-P) and the Generalitat de Catalunya (2017-SGR-1414).Peer ReviewedPostprint (author's final draft

    Concurrent Systems Need Both Sequences And Serializers

    Get PDF
    This report describes research done at the Artificial Intelligence Laboratory of the Massachusetts Institute of Technology. Support for the laboratory's artificial intelligence research is provided in part by the Office of Naval Research of the Department of Defense under contract N00014-75-C-0522.Contemporary concurrent programming languages fall roughly into two classes. Languages in the first class support the notion of a sequence of values and some kind of pipelining operation over the sequence of values. Languages in the second class support the notion of transactions and some way to serialize transactions. In terms of the actor model of computation this distinction corresponds to the difference between serialized and unserialized actors. In this paper the utility of modeling both serialized and unserialized actors in a coherent formalism is demonstrated.MIT Artificial Intelligence Laboratory Department of Defense Office of Naval Researc

    Reactive programming in Ada 2012 with RxAda

    Get PDF
    The ReactiveX API, also known as the Reactive Extensions in the. NET world, is a popular functional reactive programming framework for asynchronous, event-based, multithreaded programming. Although Ada built-in tasking reduces the dire needs for additional multithreading support of some other languages, the reactive approach has properties that are well-suited to the safety and maintainability culture predominant in the Ada world, such as complexity reduction, well-defined concurrency semantics, and enhanced legibility by means of concise and explicit information flows appealing to imperative reasoning. This work presents the design of a ReactiveX Ada implementation that aims to balance desirable library properties such as compile-time type-safety, amount of user-required generic instantiations, and a smooth learning curve for both library clients and maintainers. Concurrency design aspects of the library are detailed, showing how the Flat_Map and Thread abstractions have been implemented following Ada programming expectations, in particular with regard to task termination. In the intervening time from its first presentation, the library has gained implemented operators to the point of having all fundamental building blocks available. With RxAda, the Ada programmer can henceforth benefit from the abundant documentation existing for the language-agnostic ReactiveX approach without stepping out of the Ada tool chain

    From FPGA to ASIC: A RISC-V processor experience

    Get PDF
    This work document a correct design flow using these tools in the Lagarto RISC- V Processor and the RTL design considerations that must be taken into account, to move from a design for FPGA to design for ASIC
    • …
    corecore