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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!esosun!hyland
From: hyland@esosun.UUCP (Steve Hyland)
Newsgroups: comp.lang.ada
Subject: Re: Message ordering
Message-ID: <68@kvasir.esosun.UUCP>
Date: Wed, 23-Sep-87 12:25:18 EDT
Article-I.D.: kvasir.68
Posted: Wed Sep 23 12:25:18 1987
Date-Received: Sat, 26-Sep-87 04:09:03 EDT
References: <8709222126.AA13646@ucbvax.Berkeley.EDU>
Reply-To: hyland@kvasir.UUCP (Steve Hyland)
Organization: SAIC, San Diego
List-Id: <comp.lang.ada>

In article <8709222126.AA13646@ucbvax.Berkeley.EDU> 8440425@wwu.EDU (Richard Golding) writes:
>
>>"... In a properly designed real-time, multiprocessor, Ada OS, where tasking
>>     across machine boundaries is implemented via messages, the design of the
>>     bus insures that the messages are received in the order that they are 
>>     sent out..."
>>
>This may be true in some tightly-coupled multiprocessor systems, but it is
>patently *not* the case in a distributed system.  For a discussion of message-
>ordering, see Agha's Actors book.  In a widely dispersed system, say across
>several millions of miles of space (in the case of remote space probes) there
>is simply *no way* you are going to be able to completely guarantee ordering.
>
>    - richard golding
>      8440425@wwu.edu

In fact LRM section 9.5 (15) specifies that there is one entry queue per
entry and that calls to that entry are queued. It goes on to say that
calls are processed in the order of arrival. That makes it mandatory
for tasking to be handled in this manner.

I think, Richard, that you are correct in your statement and that such
a system as you predicate makes it difficult to implement this. I'd go
on to say that MANY systems will run into problems when not tightly-coupled.
So, although the LRM supports message queueing, I would say that any system
that relies on entries being queued in order of arrival is as erroneous as
one which relies on order of elaboration, etc. This means that in a system
such as you suggest, proper design of the entries and the accept statements
must be done to ensure the correct ordering.

Actually, though, as I think about this, this is less of a problem inherent
in the language as it is a design problem in communication between two
co-operating software systems. When you look at it this way, then you
probably need a front end task receiving and ordering your messages prior
to calling a particular entry.

Steve Hyland
SAIC