Joyce(ID:1330/joy002)Simplified experimental Concurrent PascalBrinch Hansen, 1981 Distributed language based on Concurrent Pascal designed to explore the programming concept of synchronous communication. Joyce had three ad hoc restrictions (Brinch Hansen 1993):
He concludes that only ythe first restriction weas neccesary People: Related languages
References: in Software - Practice & Experience, 17(01) January 1987 view details Introduction Joyce is a progrsmming language for distributed systems based on CSP. A program written in Joyce defines concurrent agents which communicate through unbuffered channels. This paper briefly describes an experimental implementation of Joyce on an Intel iPSC hypercube. The paper concentrates on experimental results and the question whether the iPSC hypercube is a suitable computer for execution of Joyce programs. Performance figures are presented in the last part of the paper. The first two sections of this paper present an overview of the Joyce programming language and the hypercube architecture Extract: The Joyce Programming Language The Joyce Programming Language A program written in Joyce consists of nested procedures which define classes of concurrent agents. An agent may activate subagents, which are executed concurrently, by executing agent statements. The outermost procedure defines an initial agent which is activated by the operating system. Recursion is allowed in Joyce (but not in CSP). Each agent has its own set of vaMables and formal parameters which are inaccessible to other agents. An agent may activate unbuffered communication devices, known as channels, and refer to these by means of port variables. A channel can transfer a defined set of symbols, known as the alphabet of the channel, each carrying an optional message of a defined type. An agent may pass values of port variables (so-called channel pointers) as actual parameters to its subagents. In this way, two or more agents may share channels. Port variables, channel alphabets and messages cannot be declared in CSP and channels cannot be shared by more than two processes. A communication between two agents takes place when one of them is ready to execute an output statement cl Is(e} and the other one is ready to execute an input statement c27s(v), where cl and c2 are port variables pointing to the same channel. Hence the agents are said to match. The symbol s is communicated and the value of the expression e (the message carried by the symbol) assigned to the variable v. A polling statement, consisting of guarded statements, enables an agent to select one of several communications. The polling statement below consists of two guarded statements - the first guard cl?sl(v) & bl with an input command cl?sl(v) and the second guard c2!s2(e) & b2 with an output command c2!s2(e) (bl and b2 are boolean expressions which are optional): poll cl?sl(v) & bl -> statementlistl 1 c2!s2(e) & b2 -> statementlist2 end The polling statement is executed until an input or output command becomes feasible (i.e., an agent becomes ready for the communication) and the corresponding boolean expression is true. The agent completes the communication and executes the corresponding statement list. Output polling is allowed in Joyce (but not in CSP). In an implementation of Joyce for the IBM PC by Per Brinch Hansen, dynamic allocation of activation records on a single stack is used2 When an agent (or channel) is activated, it is assigned an agent record (or a channel record). When an agent terminates and all its subagents are marked as being dead, the record of the agent as well as the records of its channels are also marked as being dead. A dead activation record is removed only when it is at the top of the stack. Agents ready to be executed are waiting in a ready queue, whereas agents waiting to communicate are waiting in symbol queues. The processor executes agents from the ready queue. A communication is handled by copying the message (if any) from a local expression stack in one agent record to the activation record of another agent. The waiting agent is then entered into the ready queue. Extract: Conclusions Conclusions My conclusion is that the first release of the iPSC hypercube is not a suitable computer for the execution of Joyce programs. To waste 3 out of 4 processors seems much too expensive. Improvements in the implementation of Joyce on the iPSC hypercube cannot be expected to cause significantly improved results. First, the communication speed can be increased by rewriting some routines in assembly language, and second, by rewriting the compiler, so machine code is produced instead of portable code, the execution speed of sequential parts of Joyce programs can be improved. Unfortunately, these optimizations will neutralize each other with respect to the speed-up. Joyce programs can be written such that the number of message exchanges is reduced, but this requires the programmer to have considerable knowledge of the hypercube architecture and the implementation of Joyce. Such requirements seem unrealistic. The portability of Joyce programs will also be lost. To effectively execute Joyce programs, an implementation on another parallel computer must be developed. A computer with shared memory or both shared memory and local memory (to reduce the load of the shared bus) in my opinion offers the best possibilities due to the high communication and activation speed demands for Joyce programs, however, other distributed computers may also be of interest and should be studied. The performance of the first version of the iPSC hypercube might be significantly improved by substituting parallel busses for the seriel Ethernet channels. In fact, this is what Intel has done with the new hypercube, iPSC/2. Unfortunately, the processor capacity has simultaneously increased and therefore, the communication/processor speed ratio is unchanged. The iPSC/2 seems not to offer better facilities for implementation of Joyce. Extract: Future Work Future Work This paper is based on my M.S. thesis which has inspired me to continue the work in the direction of fine-grained and middle-/coarse-grained concurrency conflicts between programming languages and machine architectures. Since such a conflict was found in the implementation of Joyce on the iPSC hypercube, I concluded that the programmer should have considerable knowledge of the hypercube architecture and the implementation of Joyce to write programs with high efficiency, i.e., with acceptable speed-ups. The programmer should not try to exploit the fine- to middle-grained concurrency in Joyce, only the middle- to coarse-grained concurrency. My opinion is that in the world of sound parallel programming, the programmer and the computer scientist, who is developing concurrent algorithms, do not need to know anything about the target machine. In the sound world, programs are written for a virtual distributed machine architecture with any number of processors interconnected by communication channels with speeds comparable to the execution time of a machine instruction. This virtual architecture might be reality in the future. The virtual architecture requires programming languages supporting finegrained concurrency. For programs written is such a language to run efficiently on currently known target machines, some (fine-grained) concurrency need to be removed from the programs at compile-time. If this is achievable, the programmer and the computer scientist can write machine independent parallel programs/algorithms which are prepared for future distributed machine architectures as well as for architectures with shared memory (or a mixture). In my Ph.D. thesis, I am investigating how to efficiently exploit parallelism in programming without knowledge of the architecture of the target machine. This investigation includes development of an object-oriented programming language, an intelligent compiler and a run-time kernel for a reconfigurable network of transputers* which are Reduced Instruction Set Computers with onchip high-speed communication links. in SIGPLAN Notices 24(08) August 1989 view details in Software - Practice & Experience, 19(06) June 1989 view details in Software - Practice & Experience, 19(06) June 1989 view details in [ACM SIGPLAN] SIGPLAN Notices 28(03) March 1993 The second ACM SIGPLAN conference on History of programming languages (HOPL II) view details |