| C. Haynes and D. Friedman. Engines build process abstractions. In Conference Record of the 1984. |
....different algorithms corresponding to different paradigms of parallelism including: result parallelism, master slave parallelism, and speculative parallelism. We have also implemented several different parallel programming models including: futures [3] first class tuple spaces [6] and engines[4] and compared them using various parallel algorithms that have been implemented in Sting. A report analyzing the relative performance and merits of the various programming models using several different algorithmic paradigms will be forthcoming. The Sting operating system architecture is composed ....
C.T. Haynes and D.P. Friedman. Engines Build Process Abstractions. In slfp84, pages 18--24, Computer Science Department, Indiana University, 1984.
....languages, the parallel and distributed systems, and the agents communities. 4.1 Engines and Sponsors Our notion of group is at the intersection of two different ideas: Haynes and Friedman s engines and Kornfeld, Hewitt, and Osborne s sponsors, which we develop below. Haynes and Friedman [19, 20] introduce the engine facility to model timed preemption; variants can also be found in [8, 9, 48] Engines differ from our groups in a number of ways. Engines are defined in a sequential framework and are used to simulate multiprogramming. Since engines do not deal with parallelism, they do not ....
Christopher T. Haynes and Daniel P. Friedman. Engines Build Process Abstractions. In Proceedings of the 1984 ACM Conference on Lisp and Functional Programming, pages 18--24. ACM, 1984.
....in several areas e.g. process scheduling in operating systems, heuristic search in AI, simulation. Primarily the ability to preempt a process from running and to be able to resume that process at a later time have been capabilities relegated to an operating system. In 1984 Haynes and Friedman [7, 8] introduced a programming language abstraction termed engines 1 for timed preemption. Engines allow a process to be preempted after a prespecified amount of computation has occurred. They also provide the ability to resume a suspended computation on demand. Engines were first introduced as an ....
Christopher T. Haynes and Daniel P. Friedman. Engines build process abstractions. Proceedings of the 1984 ACM Conference on Lisp and Functional Programming, pages 18--24, 1984.
....that the eldest local group is allowed to notify its parent of its exhaustion. 6 Discussion and Related Work Our notion of group is at the intersection of two different ideas: Haynes and Friedman s engines and Kornfeld, Hewitt, and Osborne s sponsors, which we develop below. Haynes and Friedman [12, 13] introduce the engine facility to model timed preemption; variants can also be found in [5, 6, 31] Engines differ from our groups in a number of ways. Engines are defined in a sequential framework and are used to simulate multiprogramming. Since engines do not deal with parallelism, they do not ....
Christopher T. Haynes and Daniel P. Friedman. Engines Build Process Abstractions. In Proceedings of the 1984 ACM Conference on Lisp and Functional Programming, pages 18--24. ACM, 1984.
....scheduler, then threads will be interrupted and rescheduled when their quanta expire. Although this is not strictly required by Dreme, it is necessary if the Process is going to give any guarantees of service to locally executing code. The current implementation uses a variation on engines [17] to implement preemptive scheduling. All of these add to the number of threads being controlled by Dreme Processes, although the additional threads may be remote. Although preemption is not fundamental to Dreme, the scheduler is, as it is otherwise impossible to implement certain concurrency ....
Christopher Haynes and Daniel Friedman. Engines build process abstractions. In Symposium on Lisp and Functional Programming, pages 18--24. ACM, 1984.
....continuations or coroutines, sufficient for constructing a scheduler that simulates multiple hardware processing elements in software. One particularly elegant design for a timed preemption facility is a mechanism known as engines, of which Dybvig and Hieb have published a general implementation [11, 9]. Engines abstract over timed preemption by providing a way to run a computation for a specified amount of time. They are sufficient to construct a user mode task scheduler. Dybvig and Hieb s engine implementation has two problems for a system in which caller and callee are mutually suspicious: 1. ....
Christopher P. Haynes and Daniel P. Friedman. Engines build process abstractions. Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, pages 18--24.
....operator of Scheme. It reifies the current continuation into a function and applies its sole argument on it, the value of this application becomes the value of the original call cc form. call cc can be used to program any sequential control operator and, at least, multitasking [Wan80] engines [HF84], escapes [HFW84] and even partial continuations From a more implementational point of view, three usages can be recognized: ffl escape operator: the continuation is only invoked once and only while in the dynamic extent of the call cc form that created it. This usage provides a setjmp longjmp ....
Christopher T. Haynes and Daniel P. Friedman. Engines build process abstractions. In Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, pages 18--24, Austin, TX., 1984.
....with or without dynamic extent stress are presented. Scheme [IEE91] offers first class continuations with indefinite extent. Pioneered in [Lan65, Rey72] continuations proved to be very useful tools allowing to program a wide variety of control features such as coroutines [Wan80] engines [HF84], escapes [HFW84] etc. The call cc function reifies [Wan86] continuations into monadic functions, transfer of control occurs when these functional objects are applied. A transformation called Continuation Passing Style (or CPS for short) exists that transforms a program using call cc into a new ....
Christopher T. Haynes and Daniel P. Friedman. Engines build process abstractions. In Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, pages 18--24, Austin, TX., 1984.
....system is used to ensure that normal order reduction is simulated and to ensure that the amount of redundant computation is minimised. Once again there is a lack of empirical evidence to support the scheme. An alternative and simpler approach has been proposed by many researchers, for example [43, 121]. This uses a notion of fuel; fuel corresponds to a quantity of evaluation which may be performed on a task, after which it is pre empted. Some, known, conservative tasks may be given an infinite amount of fuel. This seems an interesting approach but again there is a lack of empirical evidence to ....
C T Haynes and D P Friedman. Engines build process abstractions. In ACM Conference on Lisp and Functional Programming, 1984.
....algebra called mu calculus [Ward Halstead 80] and showed that all control transfer could be expressed in terms of that algebra. Functional languages that support concurrent execution and first class continuations have been successful in implementing the former in terms of the latter [Wand 80, Haynes Friedman 84, Cooper Morrisett 90] These efforts, however, have concentrated on control transfer at user level between contexts in the same address space. Functional languages 4 Even when kernel stacks are pageable, threads run often enough that their stacks remain in memory. With MK32, for example, we ....
Haynes, C. T. and Friedman, D. P. Engines Build Process Abstractions. In Conference Record of the 1984 ACM Symposium on LISP and Functional Programming, pages 18--23, August 1984.
....nonlocal exits, exceptions, nonblind backtracking [28] This material is based on work supported in part by the National Science Foundation under grant numbers CDA 9312614 and CDA 93 03189. 2 KUMAR, BRUGGEMAN, AND DYBVIG nondeterministic computations [8, 14] coroutines [12] and multitasking [7, 15, 30], at the source level. Subcontinuations are more expressive than traditional continuations and may be used to implement similar control structures in the presence of tree structured concurrency [16, 17] This article describes a thread based implementation of one shot subcontinuations that has ....
....capture mechanism from the continuation abort mechanism. Gunter, et al. 13] describe how support for multiple prompts may be added to statically typed languages. On a uniprocessor, both traditional and functional continuations are sufficient to implement multitasked threads at the source level [7, 15, 30]. Thus, many systems that support continuations provide no primitive support for threads. Continuations have also been used to implement threads on multiprocessors. MP [29] is a low level interface designed to provide a portable multiprocessing platform. It provides an abstraction of a physical ....
Haynes, Christopher T. and Friedman, Daniel P. Engines build process abstractions. In Proceedings of the 1984 ACM Conference on Lisp and Functional Programming (August 1984) 18--24.
....in C) support routines. Like ESTEREL, Teapot supports verification and can be translated to executable code. Teapot differs from ESTEREL in that its emphasis is on simplifying the task of programming complicated finite state machines. Continuations can express coroutines [13] and parallelism [12, 27]. However, few domain specific languages exploit continuations, perhaps because of concerns about their implementation complexity and cost. Teapot demonstrates that a restricted form of this feature can be implemented easily and efficiently, without losing its benefits. Draves et al. 10] used ....
Christopher T. Haynes and Daniel P. Friedman. Engines Build Process Abstractions. In Conference Record of the 1984 ACM Symposium on LISP and Functional Programming, pages 18--24, August 1984.
....and setState, replayTo and recordTo, and the cache functions described in Section 7.5. The code is quite imperative in style. It would be possible to present the basic time travel functions as side effect free transformations from states to states, giving them something of the flavor of engines (Haynes and Friedman, 1984). However, since parts of the state especially the mutable store are expensive to save and restore, we make the notion of a current state explicit and discourage excessive saves and restores. In practice, the time travel primitives are complicated somewhat by the need to handle multiple ....
Haynes, C. T. and Friedman, D. P. (1984). Engines build process abstractions. In Proc.
No context found.
Christopher T. Haynes and Daniel P. Friedman. Engines build process abstractions. In Conference Record of the 1984 ACM Symposium on Lisp and Functional Programming, pages 18--24.
No context found.
C. Haynes and D. Friedman. Engines build process abstractions. In Conference Record of the 1984.
Online articles have much greater impact More about CiteSeer.IST Add search form to your site Submit documents Feedback
CiteSeer.IST - Copyright Penn State and NEC