Transformations for early reply and forward message passing mechanisms

Abstract

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

RJ: a Java package providing JR‐like concurrent programming

“…One of our motivations behind developing RJ was to make it simpler to experiment with concurrent programming features. As one example, we made the RJ implementation of noop more object‐oriented, as described in . As another example, we changed the behaviors of reply and forward.…”

“…JR also provides a reply statement and a forward statement as forms of, respectively, early and deferred reply . These statements apply to the invocation that is being serviced by the enclosing operation method or enclosing inni statement.…”

“…Parts of RJ's implementation, like JR's, use transformations in the following ways (using JR terminology): replace synchronous invocations (call) with asynchronous invocations (send) (as noted earlier in Section 3.5); replace forward and reply with asynchronous invocation ; and replace the concurrent invocation statement with other forms of invocation and inni. …”

“…As noted earlier in Section 2.2, RJ uses an object‐oriented approach to operations. RJ handles noop as part of its operation class hierarchy, versus JR's special‐case handling, as described in .…”

“…replace synchronous invocations (call) with asynchronous invocations (send) [16] (as noted earlier in Section 3.5); replace forward and reply with asynchronous invocation [16]; and replace the concurrent invocation statement with other forms of invocation and inni. [26] 704 R. A. OLSSON AND T. WILLIAMSON…”