Browse Prior Art Database

Stimulating Shared Buffer Communication in a Distributed Processing Environment

IP.com Disclosure Number: IPCOM000108086D
Original Publication Date: 1992-Apr-01
Included in the Prior Art Database: 2005-Mar-22

Publishing Venue

IBM

Related People

Amit, N: AUTHOR [+3]

Abstract

A sequential (single-thread) computer program is partitioned into several partitions in order to be executed distributively: each partition is to run on a different machine. The partitions are generated by a program partitioning tool (PPT) and use an underlying remote procedure call (RPC) mechanism to communicate at the application level. When an RPC is issued, the data to send and receive within the RPC protocol are written out and read in to/from a communication buffer. The buffer is "shared" between the two partitions involved in the RPC transaction. The problem is how to implement the RPC mechanism so that it will have the sense that it is using a shared buffer -- thus hide the fact that the buffer is actually copied between the disparate memories of the two processes.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 13% of the total text.

Stimulating Shared Buffer Communication in a Distributed Processing Environment

       A sequential (single-thread) computer program is
partitioned into several partitions in order to be executed
distributively: each partition is to run on a different machine.  The
partitions are generated by a program partitioning tool (PPT) and use
an underlying remote procedure call (RPC) mechanism to communicate at
the application level.  When an RPC is issued, the data to send and
receive within the RPC protocol are written out and read in to/from a
communication buffer.  The buffer is "shared" between the two
partitions involved in the RPC transaction.  The problem is how to
implement the RPC mechanism so that it will have the sense that it is
using a shared buffer -- thus hide the fact that the buffer is
actually copied between the disparate memories of the two processes.
Since the fact that two independent processes are involved is not
hidden (the RPC mechanism dictates that), synchronization events
occur at specific points in the RPC protocol.

      An RPC transaction occurs between two partitions when code in
one partition issues a call to a routine which resides in a different
partition.  The partitioning tools (PPT) generate stubs to help
implement the RPC.  There is a client stub which is a module residing
within the client partition (Note 1), and a server stub, which is a
module re siding within the server partition (Note 2).  An RPC begins
to execute as a local call to a procedure in the client stub.  There,
the RPC protocol starts.  This protocol distinguishes in an RPC
transaction two parts: A call transaction and a reply transaction.
Between these two events, the server partition may take on the role
of a client when its code calls procedures in other partitions (maybe
even in the partition which performed the previous RPC to this one).
A special code layer called agent handles the proper binding
information which supports these back and forth calls.  (The agent is
not in the scope of this report.)

      Each RPC transaction part (call or reply) includes transfer of
control information to the agent so it can resolve the destination
partition for the call, and date (parameters) to be transferred
(marshalled) across. Parameters are marshalled using a mechanism
called exchange data representation (XDR) which is based on SUN* RPC.
This method requires that the encoded version of the parameters be
written out (or read in) to/from a buffer or a communication package.
When using shared memory communication, the XDR mechanism writes and
reads parameters to/from a buffer.  A circular buffer is an object
(Note 3) which permits the communicating partners continuous read/
write.

      When the two partitions reside on different machines which do
not have shared memory, the situation can be simulated while also
allowing to control the flow of data across the machines in an
attempt to optimize on the specific characteristic...