OmpSs (OMPSs) is an eort to integrate features of the StarSs program-
ming model into a single p... more OmpSs (OMPSs) is an eort to integrate features of the StarSs program- ming model into a single programming language. OpenMP (OMP) [?] is used a as a base language. OMPSs is a subset of the OMP programming language enhanced with StarSs features that allow data parallelism. OMPSs improves on OMP by providing asynchronous task parallelism, better task granularity, and heterogeneous device support. However, OMPSs does not provide full support for OMP functionalities such as fork-join parallelism, fully shared memory, and intertask communication. In particular, in OMPSs the memory is shared over time only, not over location. Thus, OMPSs memory model diers from OMP memory model. Understanding the OMPSs memory model is important to allow for the introduction of sophisticated compiler-level and machine code level optimizations. In this paper we present the OMPSs memory model. We use the OMP memory model primitives as building blocks to dene the OMPSs memory model. We explore how OMPSs is different from OMP and how that affects the OMPSs memory model. We prove that OMPSs conforms to a sequential memory model.
This position paper advocates the use of the well defined and provable self-stabilization propert... more This position paper advocates the use of the well defined and provable self-stabilization property of a system , to achieve the goals of the self-* paradigms and au-tonomic computing. Several recent results starting from hardware concerns, continuing with the operating system , and ending in the applications, are integrated: the self-stabilizing microprocessor, with the self-stabilizing operating system, the self-stabilization preserving compiler , and the self-stabilizing autonomic recoverer for applications.
Real life situations may require an drastic change in a program (control), rather than incrementa... more Real life situations may require an drastic change in a program (control), rather than incremental update, e.g. changing a control in an airplane or in an atomic reactor that experience an unexpected disaster emergency scenario. We suggest a formal framework for automatic runtime control search. We present a catalog of control search algorithms for various settings of an execution environment. The considered environment properties are: (i) determinism – an environment can be either deterministic or probabilistic, (ii) state reflection that allows observation of the current state of the environment, (iii) state set that generalizes the reset capability, allowing setting the environment to a particular state, and (iv) (static or dynamic) replication that allows instantiation of replicas for parallel execution of candidate controls. In deterministic environment settings, a control search algorithm creates all candidate programs, executes them in parallel on environment replicas, and returns a program that respects desired specifications. In probabilistic environment settings, a control search algorithm learns the environment probabilistic automaton, and then the control search algorithm is performed in run time, deciding on a next step based on a current state.
Real life situations may require an automatic fast update of the control of a plant, whether the ... more Real life situations may require an automatic fast update of the control of a plant, whether the plant is an airplane that needs to overcome an emergency situation due to drastic environment change, or a process that needs to continue executing an application in spite of a change in operating system behavior. Settings for run-time control search are defined, assuming the environment may be totally dynamic, but is reentrant and history oblivious for long enough periods. On-line experiments on the environment assist in the implementation of unrealizable specifications given the behavior restriction of the current environment. A successful search for a control implicitly identifies the weakly realiz-able specifications, and explicitly identifies the implementation that respects the specifications. Various settings and capabilities of the plant are investigated. In particular, (i) plant state reflection that allows observation of the current state of the plant, (ii) plant state set that generalizes the re-set capability, allowing setting the plant to each of its states, and (iii) (static or dynamic) plant replication that allows instantiation of plant replicas or use of pre-existing plant replicas for parallelizing testing algorithms. The presented algorithms show that the above capabilities enable a polynomial search for a new control upon a drastic change of the environment.
We introduce the recovery oriented programming paradigm. Programs that are designed according to ... more We introduce the recovery oriented programming paradigm. Programs that are designed according to the recovery oriented programming paradigm include, as an integral part, the important safety and liveness properties that the program should respect and the recovery actions that should be executed upon a violation of these properties. We design a pre-compiler that compiles the properties and recovery actions into a code snippet for monitoring properties and enforcing recovery actions upon property violation. Assuming the restartability property of a given program and the existence of a self-stabilizing software platform, the compiled program is able to recover from safety and live-ness violations. We provide a generic correctness proof scheme for recovery oriented programs, proving that the code, as transformed by the pre-compiler, converges to a legal execution in a finite number of steps after experiencing an arbitrary failure.
We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the ... more We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the package. We assume that if a program is started in a predefined initial state, it will exhibit legal behavior for a period of time but will eventually become Byzantine. We assume that this behavior pattern can be attributed to the fact that the manufacturer had performed sufficient package tests for limited time scenarios. Restarts are useful for recovering such systems. We suggest a general, yet practical, framework and paradigm for the monitoring and restarting of systems where the framework and paradigm are based on a theoretical foundation. An autonomic recoverer that monitors and initiates system recovery is proposed. It is designed to handle a task, given specific task requirements in the form of predicates and actions. A directed acyclic graph subsystem hierarchical structure is used by a consistency monitoring procedure for * An extended abstract of this work was presented at the 1 achieving a gracious recovery. The existence and correct functionality of the autonomic recovery is guaranteed by the use of a self-stabilizing kernel resident (anchor) process. The autonomic recoverer uses a new scheme for liveness assurance via on-line monitoring that complements known schemes for on-line safety assurance.
We suggest to model software package flaws (bugs) by assuming eventual Byzantine behavior of the ... more We suggest to model software package flaws (bugs) by assuming eventual Byzantine behavior of the package. In particular, the package has been tested by the manufacturer for limited length scenarios when started in a predefined initial state; the behavior beyond the tested scenario may be Byzantine. Restarts (reboots) are useful for recovering such systems. We suggest a general yet practical framework and paradigm, based on a theoretical foundation, for the mon-itoring and restarting of systems. An autonomic recoverer that monitors and restarts the system is proposed, where: The autonomic recoverer is designed to handle different tasks given specific task requirements in the form of pred-icates and actions. DAG subsystem hierarchy structure is used by a consistency monitoring procedure in order to achieve gracious recovery. The existence and correct func-tionality of the autonomic recovery is guaranteed by the use of a kernel resident (anchor) process, and the design of the process t...
Proceedings of the twentieth ACM symposium on Operating systems principles - SOSP '05, 2005
Computerized management of critical systems makes the issues of correctness and faultless flow of... more Computerized management of critical systems makes the issues of correctness and faultless flow of long-lived and continuously-running programs extremely important e.g., [6, 7]. Complex systems cannot be fully verified because their verification may require an unreasonable amount of time and space. The software industry tests software products extensively in order to eliminate bugs as much as possible. Normally, software is
We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the ... more We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the package. We assume that if a program is started in a predefined initial state, it will exhibit legal behavior for a period of time but will eventually become Byzantine. We assume that this behavior pattern can be attributed to the fact that the manufacturer had performed sufficient package tests for limited time scenarios. Restarts are useful for recovering such systems. We suggest a general, yet practical, framework and paradigm ...
International Journal on Software Tools for Technology Transfer, 2011
Abstract We introduce the recovery-oriented programming paradigm. Programs that are designed acco... more Abstract We introduce the recovery-oriented programming paradigm. Programs that are designed according to the recovery-oriented programming paradigm include, as an integral part, the important safety and liveness properties that the program should respect and the recovery actions that should be executed upon a violation of these properties. We design a pre-compiler that compiles the properties and recovery actions into a code snippet for monitoring properties and enforcing recovery actions upon property violation. Assuming ...
OmpSs (OMPSs) is an eort to integrate features of the StarSs program-
ming model into a single p... more OmpSs (OMPSs) is an eort to integrate features of the StarSs program- ming model into a single programming language. OpenMP (OMP) [?] is used a as a base language. OMPSs is a subset of the OMP programming language enhanced with StarSs features that allow data parallelism. OMPSs improves on OMP by providing asynchronous task parallelism, better task granularity, and heterogeneous device support. However, OMPSs does not provide full support for OMP functionalities such as fork-join parallelism, fully shared memory, and intertask communication. In particular, in OMPSs the memory is shared over time only, not over location. Thus, OMPSs memory model diers from OMP memory model. Understanding the OMPSs memory model is important to allow for the introduction of sophisticated compiler-level and machine code level optimizations. In this paper we present the OMPSs memory model. We use the OMP memory model primitives as building blocks to dene the OMPSs memory model. We explore how OMPSs is different from OMP and how that affects the OMPSs memory model. We prove that OMPSs conforms to a sequential memory model.
This position paper advocates the use of the well defined and provable self-stabilization propert... more This position paper advocates the use of the well defined and provable self-stabilization property of a system , to achieve the goals of the self-* paradigms and au-tonomic computing. Several recent results starting from hardware concerns, continuing with the operating system , and ending in the applications, are integrated: the self-stabilizing microprocessor, with the self-stabilizing operating system, the self-stabilization preserving compiler , and the self-stabilizing autonomic recoverer for applications.
Real life situations may require an drastic change in a program (control), rather than incrementa... more Real life situations may require an drastic change in a program (control), rather than incremental update, e.g. changing a control in an airplane or in an atomic reactor that experience an unexpected disaster emergency scenario. We suggest a formal framework for automatic runtime control search. We present a catalog of control search algorithms for various settings of an execution environment. The considered environment properties are: (i) determinism – an environment can be either deterministic or probabilistic, (ii) state reflection that allows observation of the current state of the environment, (iii) state set that generalizes the reset capability, allowing setting the environment to a particular state, and (iv) (static or dynamic) replication that allows instantiation of replicas for parallel execution of candidate controls. In deterministic environment settings, a control search algorithm creates all candidate programs, executes them in parallel on environment replicas, and returns a program that respects desired specifications. In probabilistic environment settings, a control search algorithm learns the environment probabilistic automaton, and then the control search algorithm is performed in run time, deciding on a next step based on a current state.
Real life situations may require an automatic fast update of the control of a plant, whether the ... more Real life situations may require an automatic fast update of the control of a plant, whether the plant is an airplane that needs to overcome an emergency situation due to drastic environment change, or a process that needs to continue executing an application in spite of a change in operating system behavior. Settings for run-time control search are defined, assuming the environment may be totally dynamic, but is reentrant and history oblivious for long enough periods. On-line experiments on the environment assist in the implementation of unrealizable specifications given the behavior restriction of the current environment. A successful search for a control implicitly identifies the weakly realiz-able specifications, and explicitly identifies the implementation that respects the specifications. Various settings and capabilities of the plant are investigated. In particular, (i) plant state reflection that allows observation of the current state of the plant, (ii) plant state set that generalizes the re-set capability, allowing setting the plant to each of its states, and (iii) (static or dynamic) plant replication that allows instantiation of plant replicas or use of pre-existing plant replicas for parallelizing testing algorithms. The presented algorithms show that the above capabilities enable a polynomial search for a new control upon a drastic change of the environment.
We introduce the recovery oriented programming paradigm. Programs that are designed according to ... more We introduce the recovery oriented programming paradigm. Programs that are designed according to the recovery oriented programming paradigm include, as an integral part, the important safety and liveness properties that the program should respect and the recovery actions that should be executed upon a violation of these properties. We design a pre-compiler that compiles the properties and recovery actions into a code snippet for monitoring properties and enforcing recovery actions upon property violation. Assuming the restartability property of a given program and the existence of a self-stabilizing software platform, the compiled program is able to recover from safety and live-ness violations. We provide a generic correctness proof scheme for recovery oriented programs, proving that the code, as transformed by the pre-compiler, converges to a legal execution in a finite number of steps after experiencing an arbitrary failure.
We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the ... more We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the package. We assume that if a program is started in a predefined initial state, it will exhibit legal behavior for a period of time but will eventually become Byzantine. We assume that this behavior pattern can be attributed to the fact that the manufacturer had performed sufficient package tests for limited time scenarios. Restarts are useful for recovering such systems. We suggest a general, yet practical, framework and paradigm for the monitoring and restarting of systems where the framework and paradigm are based on a theoretical foundation. An autonomic recoverer that monitors and initiates system recovery is proposed. It is designed to handle a task, given specific task requirements in the form of predicates and actions. A directed acyclic graph subsystem hierarchical structure is used by a consistency monitoring procedure for * An extended abstract of this work was presented at the 1 achieving a gracious recovery. The existence and correct functionality of the autonomic recovery is guaranteed by the use of a self-stabilizing kernel resident (anchor) process. The autonomic recoverer uses a new scheme for liveness assurance via on-line monitoring that complements known schemes for on-line safety assurance.
We suggest to model software package flaws (bugs) by assuming eventual Byzantine behavior of the ... more We suggest to model software package flaws (bugs) by assuming eventual Byzantine behavior of the package. In particular, the package has been tested by the manufacturer for limited length scenarios when started in a predefined initial state; the behavior beyond the tested scenario may be Byzantine. Restarts (reboots) are useful for recovering such systems. We suggest a general yet practical framework and paradigm, based on a theoretical foundation, for the mon-itoring and restarting of systems. An autonomic recoverer that monitors and restarts the system is proposed, where: The autonomic recoverer is designed to handle different tasks given specific task requirements in the form of pred-icates and actions. DAG subsystem hierarchy structure is used by a consistency monitoring procedure in order to achieve gracious recovery. The existence and correct func-tionality of the autonomic recovery is guaranteed by the use of a kernel resident (anchor) process, and the design of the process t...
Proceedings of the twentieth ACM symposium on Operating systems principles - SOSP '05, 2005
Computerized management of critical systems makes the issues of correctness and faultless flow of... more Computerized management of critical systems makes the issues of correctness and faultless flow of long-lived and continuously-running programs extremely important e.g., [6, 7]. Complex systems cannot be fully verified because their verification may require an unreasonable amount of time and space. The software industry tests software products extensively in order to eliminate bugs as much as possible. Normally, software is
We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the ... more We suggest modeling software package flaws (bugs) by assuming eventual Byzantine behavior of the package. We assume that if a program is started in a predefined initial state, it will exhibit legal behavior for a period of time but will eventually become Byzantine. We assume that this behavior pattern can be attributed to the fact that the manufacturer had performed sufficient package tests for limited time scenarios. Restarts are useful for recovering such systems. We suggest a general, yet practical, framework and paradigm ...
International Journal on Software Tools for Technology Transfer, 2011
Abstract We introduce the recovery-oriented programming paradigm. Programs that are designed acco... more Abstract We introduce the recovery-oriented programming paradigm. Programs that are designed according to the recovery-oriented programming paradigm include, as an integral part, the important safety and liveness properties that the program should respect and the recovery actions that should be executed upon a violation of these properties. We design a pre-compiler that compiles the properties and recovery actions into a code snippet for monitoring properties and enforcing recovery actions upon property violation. Assuming ...
Uploads
ming model into a single programming language. OpenMP (OMP) [?] is used a as a base language. OMPSs is a subset of the OMP programming language enhanced with StarSs features that allow data parallelism.
OMPSs improves on OMP by providing asynchronous task parallelism, better task granularity, and heterogeneous device support. However, OMPSs does not provide full support for OMP functionalities such as fork-join parallelism, fully shared memory, and intertask communication. In particular, in OMPSs the memory is shared over time only, not over location. Thus, OMPSs memory model diers from OMP memory model.
Understanding the OMPSs memory model is important to allow for the
introduction of sophisticated compiler-level and machine code level optimizations. In this paper we present the OMPSs memory model. We use the OMP memory model primitives as building blocks to dene the OMPSs memory model. We explore how OMPSs is different from OMP and how that affects the OMPSs memory model. We prove that OMPSs conforms to a sequential memory model.
ming model into a single programming language. OpenMP (OMP) [?] is used a as a base language. OMPSs is a subset of the OMP programming language enhanced with StarSs features that allow data parallelism.
OMPSs improves on OMP by providing asynchronous task parallelism, better task granularity, and heterogeneous device support. However, OMPSs does not provide full support for OMP functionalities such as fork-join parallelism, fully shared memory, and intertask communication. In particular, in OMPSs the memory is shared over time only, not over location. Thus, OMPSs memory model diers from OMP memory model.
Understanding the OMPSs memory model is important to allow for the
introduction of sophisticated compiler-level and machine code level optimizations. In this paper we present the OMPSs memory model. We use the OMP memory model primitives as building blocks to dene the OMPSs memory model. We explore how OMPSs is different from OMP and how that affects the OMPSs memory model. We prove that OMPSs conforms to a sequential memory model.