From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!dciem!nrcaer!sce!jeffw
From: jeffw@sce.carleton.ca (Jeff Wilson)
Newsgroups: comp.lang.ada
Subject: Timing in distributed Ada programs
Keywords: Ada timing, timed entry calls, timing delays
Message-ID: <699@sce.carleton.ca>
Date: 8 Nov 89 20:37:38 GMT
Organization: Systems & Computer Eng. Dept., Carleton University, Ottawa, Canada
List-Id: <comp.lang.ada>


     A couple of weeks ago I posted an item requesting
clarification of some timing issues with respect to Ada.
In particular, what does the time REALLY mean in a timed
entry call?  Is it the total time the calling task is
willing to wait (including any communication overhead), or
is it the time the calling task is willing to wait in the
called task's queue (independent of communication overhead)?

     The responses indicate that there is no consensus, and
in fact, each interpretation has its merits.  For distributed
systems, communication overhead MUST be considered because it
may affect how the software is designed, particularly in
regards to task-to-node allocation.  However, a consistent
model is needed such that a conditional entry call is the same
as a timed entry call with a delay of zero.

     I think one's interpretation depends on how a rendezvous
is viewed.  If it is viewed from the calling task's perspective,
the specified time includes communication overhead.  If it is
viewed from the called task's point of view, the communication
overhead is ignored.

     I propose a method which allows both interpretations to be
used in the same call:  rather than giving one time, associate
with a timed entry call a total delay time AND a queue delay time.
The total delay time is managed on the calling task's processor
while the queue delay time is managed on the called task's
processor.  Pluses of this method are:

- if the called task's processor fails during the timeout period,
  there is still a record of the calling task so it can be revived
- it gives a more complete specification of the timing component
  of the interaction

Minuses of this method are:

- the possibility of data inconsistency exists because information
  is kept in two places (some sort of protocol would be needed to
  ensure both tasks agree about the state of the rendezvous)
- Ada doesn't support it, nor does any other language I know

Why should we have to settle for one interpretation when it doesn't
fit our application?  This method allows one or both of them to be
used as necessary.  Ignoring the syntax and implementation details,
does this method bridge the gap?

Jeff Wilson
Systems & Computer Engineering
Carleton University
Ottawa, Ontario, Canada
jeffw@sce.carleton.ca