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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	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!husc6!rutgers!ucla-cs!zen!ucbvax!telesoft.UUCP!tom
From: tom@telesoft.UUCP (Tom Quiggle @spot)
Newsgroups: comp.lang.ada
Subject: Re: a question
Message-ID: <8708272127.AA01752@sdcsvax.UCSD.EDU>
Date: Thu, 27-Aug-87 17:16:29 EDT
Article-I.D.: sdcsvax.8708272127.AA01752
Posted: Thu Aug 27 17:16:29 1987
Date-Received: Sat, 29-Aug-87 13:00:12 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

> VAx Ada(tm) LRM 9.5.13 (?) says: If several tasks call the same entry
                  ^^^^^^
FYI:              9.5(15)  ANSI-STD-1815A-1983
> before a corresponding accept statement is reached, the calls are queued.
> ..
> The calls are processed in the order of arrival.
> 
> My question is: Are those entry calls queued in the order of calls?
> In other words, is the order of call the same as that of arrival?
> 
> -- Haerim Lee (IE53@NTSUVAX)
> 

Not necessarily:

In a loosely coupled distributed system, there is a discernable delay
between the moment when an entry call is made and the moment the call is
placed on the associated entry queue.  Depending on the characteristics
of the underlying communication system, multiple messages requesting that 
calls be placed on an entry queue may not reach the destination machine
in the order in which the messages were presented to the communication
system; therefore the callers may not be queued in the order the calls 
were generated.

On a uniprocessor system there is still a finite amount of processing which
must take place in order to execute an entry call.  LRM 9.5(10) states:

    Execution of an entry call statement starts with the evaluation 
    of the entry name; this is followed by any evaluations required 
    for actual parameters in the same manner as for a subprogram call
    (see 6.4).

[Presumably the enqueuing of the call on the associated entry queue occurs
immediately after the entry name and actual parameters have been evaluated;
although the LRM does not explicitly state this.  One could argue that an
implementation is free to schedule any task it chooses at this point, and
therefore the answer to your question is NO.  A reasonable implementation
will not take this attitude, so I will further consider the question.]

If during the execution of the entry call statement (i.e. the evaluation of
the entry name and actual parameters) another task with higher priority
becomes eligible for execution (say by completion of a delay statement), the 
execution of the entry call can be suspended.  If this higher priority task 
proceeded to call the same entry, it will be queued first.

As a further aside, the evaluation of the actual parameters to the entry
call may result in scheduling actions which alter the order of arrival of
entry calls.  For instance the evaluation of an actual parameter may include 
a call to a function which itself calls the same entry.

Tom

-- 
Tom Quiggle                     TeleSoft                  (619)457-2700x158

                                ucbvax--|   hp-sdd--|
telesoft!tom@UCSD.ARPA		decvax--+--sdcsvax--+--telesoft
				 ihnp4--|  noscvax--|