Java provides a clean object-oriented programming model and allows for inherently systemindependent programs. Unfortunately, Java has a limited concurrency model, providing only threads and remote method invocation (RMI).The JR programming language extends Java to provide a rich concurrency model, based on that of SR. JR provides dynamic remote virtual machine creation, dynamic remote object creation, remote method invocation, asynchronous communication, rendezvous, and dynamic process creation. JR's concurrency model stems from the addition of operations (a generalization of procedures) and JR supports the redefinition of operations through inheritance. JR programs are written in an extended Java and then translated into standard Java programs. The JR run-time support system is also written in standard Java.This paper describes the JR programming language and its implementation. Some initial measurements of the performance of the implementation are also included.
Message passing notations (language, package, etc.) typically include some form of asynchronous or synchronous invocation. In a synchronous invocation, the invoker waits for the invocation's servicer to pass back results. Some message passing notations also include early reply or deferred reply (including forwarding), which alters how and when the servicer passes back its results; this additional flexibility is useful in realistic applications. It is well known how to transform a synchronous invocation into only asynchronous invocations. This paper extends such transformations to early reply and forward. This paper also describes the use of these transformations within the implementations of programming notations. Using the transformation simplifies the implementation without significantly affecting run-time costs.In a synchronous invocation, the invoker waits for the invocation's servicer to pass back results. The servicer normally does so at the end of its code for servicing the invocation and then typically waits to be invoked again or simply terminates. In some cases, however, the servicer may find it beneficial to use an early reply or deferred reply in servicing invocations [29][30][31][32]. An early reply allows the servicer to pass back results to the invoker before it finishes executing all of its code associated with servicing the invocation. A deferred reply means that the servicer puts off its replying to the invoker, but the servicer or some other process will later reply to the invoker. One particular form of deferred reply is forwarding, where the servicer passes on the responsibility for replying to the invoker to another process. Because this paper focuses on the forward form of deferred reply, it uses the unqualified term 'reply' to mean early reply.Early reply is useful, for example, when the servicer has computed the invocation's return value but has additional activities associated with the invocation that it still needs to perform, for example, the servicer needs to close a file or write logging information. The early reply allows the invoker to proceed after its invocation without waiting for the servicer to complete its clean-up activities, which can improve performance. Early reply is also useful when the servicer needs to provide to the invoker some private information, for example, to facilitate conversational continuity [29].Forward is useful, for example, in typical client-server interactions. Instead of servicing all invocations itself, the server can act as an intermediary and forward the invocations to one of many workers in a pool of workers. This use of forward can also improve overall performance because many workers can be handling invocations at the same time.It is well known (e.g., [29] and [23]) how to transform a synchronous invocation into only asynchronous invocations. This paper extends such transformations to deal with mechanisms for early reply and forward. This paper makes the following contributions. It shows how, via transformations, to describe and understand early...
Inexperienced and novice programmers in CS 1 are often faced with the expectation that they will be able to decompose a problem into subproblems, solve these subproblems independently, and then recompose these solutions. As with programming in general, decomposition is a skill that benefits from explicit instruction and that must be practiced to see improvement. This paper introduces a term-long project approach to CS 1 that emphasizes program decomposition. Existing software quality metrics are used to assess student decomposition progression through the project and to compare the decomposition skills of students in courses using the term-long project approach against those in courses using a more typical "stand-alone" project approach.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.