From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,MSGID_SHORT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 25 May 91 22:23:49 GMT
From: taurus!aldebaran!schweige@lll-winken.llnl.gov  (Jeffrey M. Schweiger)
Subject: C.A.R. Hoare on Ada - 1985
Message-ID: <2297@aldebaran.cs.nps.navy.mil>
List-Id: <comp.lang.ada>

There was recently some discussion regarding some comments made regarding Ada
by C.A.R. Hoare in 1980, three years before the establishment of the ANSI/DoD
standard for Ada.  While focusing on a specific portion of Ada, I thought that
some comments made by Professor Hoare with respect to Ada in 1985 might be of
interest.

The following is excerpted from C.A.R. Hoare, "Communicating Sequential 
Processes", Chapter 7, Prentice-Hall, 1985:

"The execution of the body of an accept is known as a rendezvous, since the 
calling and accepting task may be thought to be executing it together.  The
rendezvous is an attractive feature of Ada, since it simplifies the very
common practice of alternating output and input, without much complicating
the case when only input or output is required.

...

    Each task in Ada may be given a fixed priority.  If several tasks are
capable of making progress, but only a lesser number or processors are
available, the tasks with lower priority will be neglected.  The priority of
execution of a rendezvous is the higher of the priority of the calling and of
the accepting tasks.  The indication of priority is called a pragma; it is
intended to improve critical response times compared with non-critical ones, and
it is not intended to affect the logical behaviour of the program.  This is an
excellent idea, since it separates concern for abstract logical correctness
from problems of real time response, which can often be more easily solved by
experiment or by judicious selection of hardware.
     Ada offera a number of additional facilities.  It is possible to test how 
many calls are waiting on an entry.  One task may abruptly terminate (abort)
another task, and all tasks dependent upon it.  Taks may access and update 
shared variables.  The effect of this is made even more unpredictable by the
fact that compiers are allowed to delay, reorder, or amalgamate such updating
just as if the variable were not shared.  There are some additional
complexities and interaction effects with other features which I have not
mentioned.
     Apart from the complexities listed in the preceding paragraph, tasking in
Ada seems to be quite well designed for implementation and use on a 
multiprocessor with shared storage."

-- 
*******************************************************************************
Jeff Schweiger	      Standard Disclaimer   	CompuServe:  74236,1645
Internet (Milnet):				schweige@taurus.cs.nps.navy.mil
*******************************************************************************