R. Chandra, A. Gupta, and J. L. Hennessy. COOL: A Language for Parallel Programming. In Languages and Compilers for Parallel Computing Conference, pages 126--147. Springer Verlag, 1992.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....such as Monitors [9] ADT with path expressions [3] and iv) actorbased approaches [1] Further, many object oriented concurrent programming languages have used C as the basis for including concurrency and synchronization. Examples of such languages are: CC [5] Mentat [8] Charm [13] COOL [4], C [2] and ACT [11] The different approaches to interaction specification in these languages can be categorized into three: i) languages that use traditional synchronization primitives such as locks and semaphores [4, 2] write once read manyvariables [5] and data flow based data ....

.... Examples of such languages are: CC [5] Mentat [8] Charm [13] COOL [4] C [2] and ACT [11] The different approaches to interaction specification in these languages can be categorized into three: i) languages that use traditional synchronization primitives such as locks and semaphores [4, 2], write once read manyvariables [5] and data flow based data dependencies [8] for specifying interaction among methods. ii) Languages such as enable based approaches [17, 22] disable based approaches [6] and behavior abstraction based approaches [12, 23, 14] that use boolean conditions to ....

R. Chandra, A. Gupta, and J. L. Hennessy. COOL: A Language for Parallel Programming. In Languages and Compilers for Parallel Computing Conference, pages 126--147. Springer Verlag, 1992.

....pipeline. The approach also gives a natural way to restrict algorithms so they have no concurrent memory accesses. The futures construct was developed in the late 70s for expressing parallelism in programming languages and has been included in several programming languages [24] 25] 15] [17], 16] Conceptually, the future construct forks a new thread t 1 to calculate Pipelining with Futures 215 a value (evaluate an expression) and immediately returns a pointer to where the result of t 1 will be written. This pointer can then be passed to other threads. When a thread t 2 needs the ....

R. Chandra, A. Gupta, and J. Hennessy. COOL: a language for parallel programming. In D. Padua, D. Gelernter, and A. Nicolau, editors, Languages and Compilers for Parallel Computing, Research Monographs in Parallel and Distributed Computing, pages 126--148. MIT Press, Cambridge, MA, 1990.

....assume that each application can use all of the nodes allocated to it during its lifetime. We also assume that these applications can be decomposed into the structure depicted in Fig. 1. This structure has been variously called bag of tasks[1, 10] master slave parallelism[25] and task queue model [15, 5]. Each application consists of a coordinator process along with a set of worker processes as shown in Fig. 1. When an application starts it spawns a set of worker processes and the logically centralized coordinator. Each worker process is given a set of tasks to work on. When a worker is finished ....

R. Chandra, A. Gupta, and J. Henessey. COOL: A Language for parallel programming. In Proceedings of the Second Workshop on Programming Languages, and Compilers for Parallel Computing, Aug. 1989.

....was an issue. C is rapidly replacing C as the language of choice for systems programming, and is starting to be adopted by scientific programmers, who have traditionally been the largest users of parallel computers. For this reason, numerous attempts have been made to add concurrency to C [2, 4, 5, 6, 7, 8, 9, 10, 12]. Most such systems require extensive compiler extensions and or preprocessors. Attempts using purely a class library approach have often not fully utilized OOP in their design and implementation, or have imposed unreasonable limitations on the users. For example, some libraries [2, 7, 8] limit ....

....neither Ppar void nor Ppar value block the caller. Instead, the calling object proceeds with its activity as soon as the arguments to the call have been copied to a safe place. Ppar void is used for asynchronous invocation of void methods; Ppar value is used when a result is expected. Futures [11, 6, 12] are used to receive results of asynchronous RMIs. A future is an instance of the Pfuture class template. When Ppar value is called, the future is marked as pending. The future is resolved when a value becomes available for it; any attempt to read its value before it is resolved blocks its reader. ....

R. Chandra, A. Gupta and J. Hennessy, "COOL: a Language for Parallel Programming", in Languages and Compilers for Parallel Computing , edited by D. Gelernter, A. Nicolau, D. Padua, MIT Press, (1990).

....These languages can be divided into three categories [5] The first category is called implicit concurrency, and consists of those languages in which, creation, synchronization, and mutual exclusion mechanisms are implicit and are encapsulated within the object. ACT [6] CHARM , 7] and COOL [8] are languages in this branch. The second category is called explicit concurrency, and consists of languages in which, creation and control of concurrency is more visible to the programmer, and there is less integration between concurrency and object oriented paradigm. Concurrent C and Extended ....

....blocks until the result is ready. Concurrent C and uC lack the future mechanism, however, it can be implemented in uC using a class which contains a semaphore to block the client, but retrieving the value of future is not simply possible. Some concurrent languages such as ACT [6] COOL [8], and CC [13] use the future variables as a useful concurrency feature. 5 Concurrent C As it was discussed earlier in this report, Concurrent C is the result of the integration of the concurrency features of Concurrent C and the data abstraction of C . Therefore Concurrent C is not an ....

Chandra R., A. Gupta, and J. Hennessy. COOL: a language for parallel programming, in Languages and Computers for Parallel Computing, edited by D. Gelernter, A. Nicolau, D. Padua, The MIT Press, Cambridge, MA, 1990.

....languages can use the compiler to provide higher level constructs, compile time type checking, and enhanced performance. C is increasingly becoming the language of choice among developers. It is therefore not surprising to see the many attempts that have been made to add concurrency to C [2, 3, 4, 9, 10, 15, 18, 19, 20, 22, 25, 27, 35, 37]. This paper reviews and analyzes some of the concurrent C based systems. We study the various approaches taken in adding concurrency to C and how these approaches interact with the object oriented paradigm. We give special attention to concurrent C systems that have used the ....

....paradigms. Concurrency, synchronization and mutual exclusion are largely implicit and encapsulated within the class definition. Concurrency is generally 7 introduced by allowing asynchronous method invocations on passive objects. Thread creation is at the time of method invocation. COOL [10] is an example of such a language. COOL [10] is an extension of C with additional constructs to create concurrency. COOL supports medium to large grain parallelism. Concurrency is created either by executing methods on different objects or by executing many methods on the same object. Private ....

[Article contains additional citation context not shown here]

R. Chandra, A. Gupta and J. Hennessy, COOL: a Language for Parallel Programming, in Languages and Compilers for Parallel Computing, edited by D. Gelernter, A. Nicolau, D. Padua, The MIT Press, 1990.

....supports no parallelism and its pSather is mainly useful for working out programs in the comfort of your own workstation. Section 6 discusses some of the basic implementation issues and how they affected the current design. The references ( 7] 8] 6] 21] 10] 29] 11] 38] 28] [17], 19] 22] 27] 30] 1] 18] 40] 43] 39] 3] 4] 5] 50] 2] 53] 52] and [16] constitute a reasonably comprehensive literature of various designs and implementations of parallel object oriented languages. The design of pSather proceeded from several basic ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. Cool: A language for parallel programming. Technical Report CSL-TR-89-396, Computer Systems Laboratory, Stanford University, October 1989.

....tolerance. None. Availability: COOL is available for the following architectures: Stanford Dash, silicon Graphics 4D 380, and Encore Multimax. Sources and Documentation can be found on anonymous ftp: cool.stanford.edu Email address: Rohit Chandra Gamma rohit cool.stanford.edu References: [55] [56] 57] 2.34 Coral Developer: IBM Palo Alto Scientific Center Description: oo. Multiple inheritance. memory model. parallelism. Asynchronous message passing. scheduling. mapping. Nothing is published about object thread placement, alignment etc. synchronization. The author states the ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: A language for parallel programming. In David Gelernter, Alexandru Nicolau, and David Padua, editors, Languages and Compilers for Parallel Computing, pages 126--148. MIT Press Cambridge, Massachusetts, London, England, 1990.

....in Cilk [8] and all computations that can be expressed in Nesl [5] Our results show that nested parallel computations have much better locality characteristics under work stealing than do general computations. We also briefly consider another class of computations, computations with futures [12, 13, 14, 20, 25], and show that they can be as bad as general computations. The second part of our results are on further improving the data locality of multithreaded computations with work stealing. In work stealing, a processor steals a thread from a randomly (with uniform distribution) chosen processor when ....

....dags G1(V1 ; E1) and G2(V2 ; E2 ) with disjoint edges sets such that s and t are the source and the sink of both G1 and G2 . Moreover V1 V2 = fs; tg. A nested parallel computation is a race free series parallel computation [6] We also consider multithreaded computations that use futures [12, 13, 14, 20, 25]. The dag structures of computations with futures are defined elsewhere [4] This is a superclass of nested parallel computations, but still much more restrictive than general computations. The work stealing algorithm for futures is a restricted form of work stealing algorithm, where a process ....

Rohit Chandra, Anoop Gupta, and John Hennessy. COOL: A Language for Parallel Programming. In David Padua, David Gelernter, and Alexandru Nicolau, editors, Languages and Compilers for Parallel Computing, Research Monographs in Parallel and Distributed Computing, pages 126--148. MIT Press, 1990.

.... group Gamma info chorus.com COOL (NTT) ACOOL [167] Phi Phi Delta Delta H H A A Phi Phi Delta Delta H H A A hijklm y t i v i t c a y r a d n u o b ftp: ftp.ntt.jp pub lang Katsumi Maruyama Gamma maruyama nttmfs.ntt.jp COOL (Stanford) [64, 65, 66] Phi Phi Delta Delta H H A A Phi Phi Delta Delta H H A A hijklm y t i v i t c a y r a d n u o b ftp: cool.stanford.edu Rohit Chandra Gamma rohit cool.stanford.edu Coral [69] Phi Phi Delta Delta H H A A Phi Phi Delta Delta H H A A y t i ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: A language for parallel programming. In David Gelernter, Alexandru Nicolau, and David Padua, editors, Languages and Compilers for Parallel Computing, pages 126--148. MIT Press Cambridge, Massachusetts, London, England, 1990.

....was an issue. C is rapidly replacing C as the language of choice for systems programming, and is starting to be adopted by scientific programmers, who have traditionally been the largest users of parallel computers. For this reason, numerous attempts have been made to add concurrency to C [2, 4, 5, 6, 7, 8, 9, 10, 12]. Most such systems require extensive compiler extensions and or preprocessors. Attempts using purely a class library approach have often not fully utilized OOP in their design and implementation, or have imposed unreasonable limitations on the users. For example, some libraries [2, 7, 8] limit ....

....neither Ppar void nor Ppar value block the caller. Instead, the calling object proceeds with its activity as soon as the arguments to the call have been copied to a safe place. Ppar void is used for asynchronous invocation of void methods; Ppar value is used when a result is expected. Futures [11, 6, 12] are used to receive results of asynchronous RMIs. A future is an instance of the Pfuture class template. When Ppar value is called, the future is marked as pending. The future is resolved when a value becomes available for it; any attempt to read its value before it is resolved blocks its reader. ....

R. Chandra, A. Gupta and J. Hennessy, "COOL: a Language for Parallel Programming", in Languages and Compilers for Parallel Computing , edited by D. Gelernter, A. Nicolau, D. Padua, MIT Press, (1990). 13

....support task (functional) parallelism are discussed in [33] Languages with data distribution features are not limited to dialects of Fortran. Distributed pC [34] adds parallel and data distribution constructs to C . Other parallel versions of C include Composition C [35] C [36] COOL [37], and CHARM [38] The pC (parallel C) programming language [39] is a parallel extension to ANSI C. Concurrent Aggregates (CA) 40, 41] is a parallel language based on LISP. A survey of object oriented parallel languages is presented in [42] 3.2 Macro Data Flow Systems The theory of partioning ....

R. Chandra, A. Gupta, and J. L. Hennessy, "COOL: A language for parallel programming, " Tech. Rep. CSL-TR-89-396, Computer Systems Laboratory, Stanford University, 1989.

....constructs. An accept( statement specifies the set of methods that the active object is prepared to serve at a given time, depending on its internal state. C [48] has increasingly become the language of choice among developers and numerous attempts have been made to add concurrency to it [6, 11, 12, 14, 18, 22, 29, 42, 43]. For a more complete review of the literature and approaches taken in adding concurrency to C see [2] Two approaches can be used to add concurrency to an object oriented language such as C . In the first approach, the language is extended in order to add the concurrency constructs. The ....

....immediately. To maximize parallelism even further, a mechanism is needed that would allow a caller to receive a result from a nonblocking RPC at some future point when the result is needed. Such a mechanism is called a future. Futures are commonly used in concurrent object oriented languages [12, 14, 29]. ABC provides blocking, nonblocking, and future RPCs. In the present prototype implementation of ABC , since we deal with general purpose registers in the marshaling of messages, the number of arguments in methods of active objects is limited to seven (that is, the number of general ....

[Article contains additional citation context not shown here]

R. Chandra, A. Gupta and J. Hennessy, COOL: a Language for Parallel Programming, in Languages and Compilers for Parallel Computing, edited by D. Gelernter, A. Nicolau, D. Padua, The MIT Press, 1990.

....gave experimental results showing the effectiveness of the technique. All this work, however, has been limited to computations in which threads can only synchronize with their sibling or ancestor threads. Although this is a reasonably general class, it does not include languages based on futures [23, 27, 12, 14, 13], languages based on lenient or speculative evaluation [1, 32] or languages with general user specified synchronization constraints [33] In this paper we show how to extend the results to support synchronization based on write once synchronization variables. A write once synchronization variable ....

....is written. Pointers to such synchronization variables can be passed around among threads and synchronization can take place between two threads that have pointers to the variable. Such synchronization variables can be used to implement futures in such languages as Multilisp [23] Mul T [27] Cool [14] and olden [13] I structures in ID [1] events in PCF [38] streams in sisal [18] and are likely to be helpful in implementing the user specified synchronization constraints in Jade [33] We model computations that use synchronization variables as directed acyclic graphs (dags) in which each ....

R. Chandra, A. Gupta, and J. Hennessy. COOL: A Language for Parallel Programming. In David Padua, David Gelernter, and Alexandru Nicolau, editors, Languages and Compilers for Parallel Computing, Research Monographs in Parallel and Distributed Computing, pages 126--148. The MIT Press, 1990.

....provide a suitable abstraction for concurrent programming has further encouraged research in this area. Various languages have been designed, some from scratch (e.g. POOL [Ame89] and ABCL [Yon90] and others by adding concurrent features to existing object oriented languages (e.g. concurrent C [CGH89] and Eiffel[Car93] Despite this broad interest, the most effective combination of the object oriented and concurrent paradigms has not yet emerged. Considerable effort has been spent in developing theoretical frameworks for studying this issue. To date, there have been two main approaches to ....

R. Chandra, A. Gupta, and J. Hennessy. COOL: A language for parallel programming. In Proc. 2nd workshop on programming languages and compilers for parallel computing, IEEE CS, 1989.

....that each application can use all of the nodes allocated to it during its lifetime. We also assume that these applications can be decomposed into the structure depicted in Figure 1. This structure has been variously called bag of tasks[1, 10] master slave parallelism[25] and task queue model [5, 14]. Each application consists of a coordinator process along with a set of worker processes as shown in Figure 1. When an application starts it spawns a set of worker processes and the logically centralized coordinator. Each worker process is given a set of tasks to work on. When a worker is ....

R. Chandra, A. Gupta, and J. Henessey. COOL: A Language for parallel programming. In Proceedings of the Second Workshop on Programming Languages, and Compilers for Parallel Computing, Aug. 1989.

....they have been successful. The difficulty in getting imperative programming languages to execute efficiently on parallel architectures without sacrificing parallelism or encumbering the user has led to the investigation into other approaches, most notably object oriented languages [LG91, CGH89, WY88] and functional programming languages [AGP78, MS82, MSA 85] 2.3.2 Functional Programming Languages Functional programming languages possess several properties that are useful for parallel programming: ffl Their operational semantics do not over specify the order of evaluation, which ....

Rohit Chandra, Anoop Gupta, and John L. Hennessy. COOL: A language for parallel programming. Technical Report CSL-TR-89-396, Stanford University, October 1989.

....methodologies, languages, and tools for implementing concurrent programs. Most languages have added constructs for specifying concurrency and synchronization in a base languages. An extensive survey of these constructs is given in [19] Examples of synchronization mechanisms are: semaphores [5, 3], write once read many variables [6] data flow based data dependencies [13] signal variables, enable based approaches [11, 18, 25, 17, 7, 12] disable based approaches [9] and behavior abstraction based approaches [14, 15] Our proposed interaction specification mechanism differs from most ....

R. Chandra, A. Gupta, and J. L. Hennessy. COOL: A Language for Parallel Programming. In Languages and Compilers for Parallel Computing Conference, pages 126--147. Springer Verlag, 1992.

....machine models with p processors. The results assume that the number of independent variable names in a program is constant. We assume the butterfly has p log 2 p switches, and the hypercube can communicate over all wires simultaneously (multiport version) all the threads waiting on the queue [22, 17, 27, 6, 20, 10, 7]. The problem is that all implementations we know of sequentialize these queues, which in turn can fully sequentialize programs that appear to be highly parallel. This will happen when all threads access the same value and get suspended on a single queue. This sort of performance anomaly is, in ....

....of time and then suspend [5] In many cases such suspension works well, but the problem with the given code is that a large number of threads will try to suspend on a single variable almost simultaneously. Current implementations sequentialize this process by using a linked list for the queue [22, 17, 6, 24, 7], and therefore would sequentialize the code. We note that a call by value semantics would not have this problem since the value of y would be computed before executing the pmap. Reading the value would require a concurrent read to the location of y, which is assumed in our machine models. Even ....

Rohit Chandra, Anoop Gupta, and John L Hennessy. COOL: a language for parallel programming. In David Galernter, Alexander Nicolau, and David Padua, editors, Languages and Compilers for Parallel Computing, Research Monographs in Parallel and Distributed Computing, chapter 8, pages 126--148. MIT Press, 1990.

....this paper is to show that many algorithms can be automatically pipelined using the futures construct, alleviating these problems. The futures construct was developed in the late 70s for expressing parallelism in programming languages [21, 6] and has been included in several programming languages [24, 25, 15, 17, 16]. Conceptually the future construct forks a new thread t1 to calculate a value (evaluate an expression) and immediately returns a pointer to where the result of t1 will be written. This pointer can then be passed to other threads. When a thread t2 with the pointer needs its value (the result of t1 ....

R. Chandra, A. Gupta, and J. Hennessy. COOL: A Language for Parallel Programming. In D. Padua, D. Gelernter, and A. Nicolau, editors, Languages and Compilers for Parallel Computing, Research Monographs in Parallel and Distributed Computing, pages 126--148. The MIT Press, 1990.

No context found.

R. Chandra, A. Gupta, and J. L. Hennessy. COOL: A Language for Parallel Programming. In Languages and Compilers for Parallel Computing Conference, pages 126--147. Springer Verlag, 1992.

No context found.

R. Chandra, A. Gupta, and J. L. Hennessy, COOL: A Language for Parallel Programming, Languages and Compilers for Parallel Computing Conference, Springer Verlag, pp. 126#147 (1992).

No context found.

R. Chandra, A. Gupta and J. L. Hennessy, `COOL: a language for parallel programming', Technical Report No. CSL-TR-89-396, University of Stanford, 1989.

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