RPC Technologies

[Philip Earnhardt]

There have been three ideas about RPC, asynchronous processing, and
multi-threaded systems that have been somewhat lost in the recent discussion:

1. Asynchronous processing is a separate issue from RPC.  Non-distributed
   applications have and will continue to use asynchronous processing.

2. One very powerful way to use RPC technology is to take an existing
   non-distributed application and use an RPC Toolkit to make it a distributed
   application.

If you want to take an existing standalone application that uses asynchronous
processing and make your asynchronous call be a remote procedure call, we feel
the most straightforward thing to do is an Asynchronous RPC call. Our
asynchronous customization provides the three things you need to do that: a
routine to invoke the remote procedure, a routine to check the status of the
procedure, and a routine to get the results of the remote procedure. There
will be existing analogues to these routines in your non-distributed
application.

Alternatively, if you want to create a multi-threaded application for doing
the remote procedure call, fine. The Netwise RPC Tool will work correctly in
multi-threaded environments. My personal opinion is that multi-threading is
the wrong tool for the job (for a variety of reasons--see below). However, it
shouldn't matter what I think--the decision should be left to the designer:

3. Asynchronous processing and multiple threads are both tools that are
   available to the developer of distributed application. Whenever possible,
   both of these methods should be available to the designer of the
   distributed application. Give the designer the choice.

My main objection to the NCS philosophy is demonstrated in Mishkin's last
message <4bc8788d.20b6d at apollo.HP.COM> :

> Asynchrony is hard to understand.  All the more reason to have a single
> abstraction -- the process/thread -- to deal with it.  

Mishkin thinks Asynchrony is hard to understand; it is not available in NCS.
Why not give the designer the choice?

The July 9, 1990 issue of UNIX Today! contains the OSF DCE Rationale and
Netwise's response to it. Hopefully, these discussions about Asynchronous RPC
will give some insight into the customization issue discussed there.

Path: brchs1!bnr.ca!rice.edu!sun-spots-request
Newsgroups: comp.sys.sun
Organization: Sunspots, Psuedo-Unmoderated
Keywords: No Digest Subjects in Unmoderated Mode
Approved: sun-spots at rice.edu

>> If you're doing asynchronous calls, you have some point when you have
>> enough information to perform the call, but don't need the result
>> immediately. A simple strategy is to go back to what you're doing until you
>> need the results, then block waiting for them.

> How do I get the results?  In a synchronous call, the results are in
> the output parameters defined in the procedure signature.  Do you create
> some other random stub procedure that just has output params or what?
> What if want to have more than one call executing concurrently?  How
> do I coordinate and collect the results?  With the multi-thread /
> synchronous call approach, the answer is create more threads and just
                             ^^^^^^^^^^
> get the result via output parameters.

The exact way that our asynchrouous customization works is that the
application performs the asynchronous call twice. The first call sends the
calling parameters and any globals needed for the call. The second call blocks
until the call is complete, updates globals and return parameters and sets the
return value. A second routine lets them check the status of the call.  As
noted above, this is pretty darn similar to what someone is doing for
asynchronous I/O in a standalone application.

If someone prefers "the answer" for his distributed application, he could
change the customization to use our select-like mechanism to check the status
of the concurrent calls. He would have changed the interface specification
to update the globals directly instead of having return parameters. They could
even have put each call in a separate thread, provided threads are available
in all environments.

I'm not too enthuiastic about "the answer" you've described, because it's
drifting away from Procedure Call semantics--the return vales for each of the
calls must also be stored in globals, too. An alternative would be to change
the customization to use the select-like mechanism to see when results are
available for each the concurrent calls, then get the results. Whatever.


>>> My religion says that they're a bad idea because they're hard to
>>> understand, represent an unnecessary new aspect in the computing model,
>>> and that one should use existing primitives for asynchrony (process) and
>>> communications (procedure call) together to achieve the same effect.

>> Do you mean that a process should fork a new thread to do the RPC call?
>> In your example, isn't the parent thread going to do stuff for "a while"
>> then "check for a result" of its child? Sounds at least as hard to me.

> Not necessarily.  I might be collecting statistics about some remote system.
> Each thread makes a call to a different system and when the result appear,
> the thread inserts the info (using mutex locks, of course) into a common
> data structure.  No one is "checking for results".
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I don't understand. Someone is waiting for all of those results to come in. It
really doesn't matter if it's looking for return values or looking at a global
data structure.

What you are proposing is still an asynchronous call!

>> For other readers: it's useful to remember one other thing about async
>> operations. Async is pretty simple to understand if there is only one
>> outstanding operation.  It is possible to have multiple async calls over a
>> connection, but the rules get much more complicated. I would not recommend
>> multiple outstanding asynchronous calls over the same connection.

> Exactly.  See my comments above.  Are you telling me async RPC is OK
> unless I want to do more than one remote thing at a time?  Seems sort
> of a limiting model.

What I'm saying is that having multiple outstanding asynchronous calls on one
id involves extra management. This is a function of having multiple
asynchronous calls over one channel--it really has nothing to do with RPC. If
you're doing a non-distributed application with asynchronous calls, it also
involves more management to support multiple outstanding asynchronous calls.

I'd imagine it's pretty complicated (or maybe impossible) in NCS to
manage multiple outstanding asynchronous calls in a single thread.  You
would probably create multiple threads. In the Netwise RPC sytsem, if you
wanted multiple async calls to the same server, you would have multiple
connection ids.

This would be extra overhead on the Netwise system. You have your choice of
separate ids for each of the asynchronous calls or non-trivial customization
to manage the calls over a separate id. Or you could examine your application
and see if it's really necessary to have multiple outstanding asynchronous
calls to the same server. The choice would rest with the designer of the
distributed system.

>> Yeah, it looks like multi-threaded systems will become more widespread. It
>> will be interesting to see what sort of problems that this unleashes on the
>> world. I'm not tremendously enthusiastic about locking out all other threads
>> every time I want to modify a global. The one that really frightens me,
>> though, is the process of software maintenance. Some junior programmer will
>> not understand THE RULES for changing a multi-threaded application and will
>> introduce bugs that will not surface for months later....

> Asynchrony is hard to understand.  All the more reason to have a single
> abstraction -- the process/thread -- to deal with it.  With a little
> language support (especially for stack-based exception handling and mutex
> locks) it's pretty tractable.  I recommend Andrew Birrell's DEC SRC tech
> report on experience programming in such an environment (SRC Report 35,
> "An Introduction to Programming with Threads").

Assuming that this package does solve the problem, what is its availability?
Is it shipping on DEC platforms? Is the technique proprietary, or is DEC
willing to give it away to everyone? Will all vendors agree to use it, or will
they invent different schemes? In short, are you willing to guarantee
interoperability for this scheme on all multi-threaded platforms? If so, when?

As noted above, what you are doing is still an asynchronous call. It's
just hidden under the threads. If Asychrony is hard to understand,
Asychrony Obfuscated by Threads should be even harder to understand.

In <4b872c9b.20b6d at apollo.HP.COM> mishkin at apollo.HP.COM (Nathaniel Mishkin) writes:

> Why do you want to invent and make me use duplicate primitves
> (in support of async RPC)?

We support Asynchronous RPC via customization.  Would NCS need to add
primitives to support Asynchronous RPC?

In <4bc8788d.20b6d at apollo.HP.COM> mishkin at apollo.HP.COM (Nathaniel Mishkin) writes:

>> Either multi-threading is a keystone of NCS, or it isn't. If
>> multithreading isn't available in all environments, then your proposed
>> mechanism of doing asynchronrous RPC via forking a thread won't work.

> Yes.  You won't be able to make concurrent calls in environments that
> don't support threading.  I also can't port my Unix programs that call
> "fork" to MS/DOS.

This hasn't really addressed the issue. Either multi-threading is a keystone
of NCS, or it isn't. If multi-threading is not available in all NCS
environments, then your proposed mechanism of doing asynchronous calls is not
portable. The presence or absence of "fork" in MS/DOS has no bearing on the
workability of Asynchronous RPC in that environment.

Phil Earnhardt          Netwise, Inc.  2477 55th St.  Boulder, CO 80301
Phone:303-442-8280      UUCP: onecom!wldrdg!pae
My opinions do not reflect any official position of Netwise.