19770715_A_Simple_Message-Passing_Facility_for_Pilot.pdf part of xerox 19770715 A Simple Message-Passing Facility for Pilot 19770715_A_Simple_Message-Passing_Facility_for_Pilot.pdf, xerox sdd memos_1977 19770715_A_Simple_Message-Passing_Facility_for

Text preview for : 19770715_A_Simple_Message-Passing_Facility_for_Pilot.pdf part of xerox 19770715 A Simple Message-Passing Facility for Pilot xerox sdd memos_1977 19770715_A_Simple_Message-Passing_Facility_for_Pilot.pdf

Back to : 19770715_A_Simple_Message | Home

Inter-Office Memorandum

To Bill Lynch Date July 15, 1977

From Hugh C. Lauer Location Palo Alto

Subject A Simple Message-Passing Organi~tion SOD/SO
Facility for Pilot
XEROX SDD ARCHIVES
XEROX I have read and understood
Pages_________To __________
Reviewer Date
Filed on: I: of Pages___.Ref., ," I ':.,r. 1 I~, "

At your request, I have prepared this memo outlining a streamlined version of a process and
message mechanism based on the philosophy of Chapter 2 of the current Pilot Functional
Specifications. The scheme described here should only be considered if the
recommendations of the Process Working Group are rejected, and then only after it has
been subjected to a careful technical scrutiny itself. The ground rule which I have followed
is that the scheme is to be implementable within the existing specifications of the Mesa
Language and DO Principles of Operations -- i.e., no changes to the compiler or microcode
are to be contemplated. For purposes of this presentation, I have deliberatedly changed all
terminology, both to be more consistent with generally accepted terminology of computer
science and to avoid confusing concepts described here with similar but not identical ones
in previous documents about Pilot.

The mechanism and interfaces described here represent a very basic set of process
communication facilities. It is hard to tell at this time whether or not a careful
implementation of these will impose an excessive amount of overhead on Pilot or its
applications (although that overhead will clearly be orders of magnitude greater than if
similar facilities were implemented in. Mesa and/or microcode). If it is felt that these
facilities are not sufficient and that additional mechanisms must be added to cater for
various special cases, then the whole scheme is likely to get out of hand very quickly,
requiring both excessive space and excessive time to execute its basic functions. Thus, I
have resisted the temptation to add extra functionality and virtual flexibility and have
instead concentrated on identifying the style of system design for which this mechanism is
most appropriate.

The Basic Mechanism

This scheme is a message-passing facility. All communication and synchronization among
processes in the system is done by passing messages. The mechanism assumes the existance
of a Ready Queue of processes (or its equivalent) ordered by priority. The processor is
always allocated to the process at the top of this queue. The message-handling operations
manipulate this queue as a side effect, thus providing the scheduling function at the
microscopic level. I do not expect that scheduling at the macroscopic level will be required for any of our
applications; but if it is, It would be provided by a process which could manIpulate the Ready Quelle
explicitly. The implementation is expected to provide buffers in which messages are
constructed, stored, and queued; this decouples the management of messages from the
management of memory and the swapping of the code and data of processes.
Simple Message-Passing System 2

Data Types

The format of a message is a fixed number of words (say, four) of unspecified type. All
message will be constructed from and interpreted as other Mesa data types by means of
loopholes.

Message: TYPE = RECORD[UNSPECIFIED, UNSI)ECIFIED, 0 0 0];

The mechanism provides a means of sending a message to a destination and optionally,
waiting for a reply to that particular message. In order to be able to identify messages for
the purpose of sorting out their replies, the following type is introduced. Objects of this
type are used by processes which originate messages.

Messageld: TYPE = PRIV ATE 0 0 0 ;

By symmetry, the mechanism provides a means for a process to receive arbitrary messages.
Such a process will operate upon the contents of a message and may choose to reply. In
order to permit that process to reply to the originator of the message without imposing on
it the burden of keeping track of who or where that originator is, the following type is
introduced.

MessageHandle: TYPE = PRIVATE RECORD[sender: Processld, msg: MessageId,
.