No abstract

No abstract

Summary The JR concurrent programming language extends Java with a richer concurrency model, by adding several new types and statements. JR provides dynamic remote virtual machine creation, dynamic remote object creation, remote method invocation, dynamic process creation, rendezvous, asynchronous message passing, semaphores, concurrent invocation, and shared variables. This paper presents RJ, a package for Java that provides JR‐like features. The paper gives an overview of RJ and its key features; describes the implications of RJ's design, including how RJ provides additional, useful flexibility; discusses the implementation of RJ; and gives qualitative and quantitative evaluations of our work with respect to feasibility and usability, experimentation, migration, and performance. RJ has been successful in meeting these goals and in providing insight into the trade‐offs between using a concurrent programming language versus using the equivalent concurrent package. Our work has yielded a few surprises in dealing with some concurrent programming language features, in understanding the run‐time performances of JR versus RJ programs, and in obtaining some additional, useful flexibility for concurrent programming applications. Copyright © 2015 John Wiley & Sons, Ltd.

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...

No abstract