Answer to 'a question'

Answer to 'a question'

[Alfred.Peterson]

Text of question::
VAx Ada(tm) LRM 9.5.13 (?) says: If several tasks call the same entry
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)

Answer::
YES.  The rules for several tasks calling an entry are the same as for one
caller as described in LRM 9.5.12.  The key is that the execution of the
calling task is suspended AFTER the queuing of the call takes place.  Only
then can the scheduler allow another task (possibly making a second call
to the same entry) to execute.  Thus 'order of call' = 'order of arrival'.

-- Spencer Peterson (asp@sei.cmu.edu) <Software Engineering Institute>

Re: Answer to 'a question'

[Gary Young]

|In article <1987.8.27.15.36.30.Alfred.Peterson@sei.cmu.edu>:
|>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)
|>Answer::
|>YES. ... The key is that the execution of the
|>calling task is suspended AFTER the queuing of the call takes place.  Only
|>then can the scheduler allow another task (possibly making a second call
|>to the same entry) to execute.  Thus 'order of call' = 'order of arrival'.
|>-- Spencer Peterson (asp@sei.cmu.edu) <Software Engineering Institute>

Unfortunately, you are assuming a single processor system.  In any distributed
or multiprocessor system, where calls are implemented via message exchange,
the "order of call" is no longer well specified.  Indeed the Ada Reference
Manual carefully leaves this to the implementation and so describes in the
introduction to chapter 9.  Even on a single processor, interupts (13.5.1)
may implement an interrupt entry call by "having the hardware directly
execute the appropriate accept statements. ... Direct calls to an interrupt
entry are allowed."  Perhaps changing the "order of call"?

Re: Answer to 'a question'

[R.A. Agnew]

In article <2181@cxsea.UUCP> young@cxsea.UUCP (Gary Young) writes:
>|>My question is: Are those entry calls queued in the order of calls?
>|>YES. ... The key is that the execution of the
>
>Unfortunately, you are assuming a single processor system.  In any distributed
>or multiprocessor system, where calls are implemented via message exchange,

Wrong! Not in any OS. 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. A common solution is a ring bus such as the SAE-9B
token-passing ring. Why would the communication of a rendezvous over a
interprocessor bus between run-time systems in different kernals be any
different than passing a message from a task to a run-time kernal
in the same processor via system services? There are many synchronization
problems to be reconed with in these implementations and that is why it has
taken Ada contractors over five years to get even close to a solution.
As an example all processors are synchronized within nanoseconds by a
"heartbeat" signal and messages are time-tagged to resolve ambiguities between
real-time events.

	********** These opinions are solely my own **************

Re: Answer to 'a question'

[David S. Rosenblum]

>>>My question is: Are those entry calls queued in the order of calls?
>>>YES. ... The key is that the execution of the
>>
>>Unfortunately, you are assuming a single processor system.  In any distributed
>>or multiprocessor system, where calls are implemented via message exchange,

>Wrong! Not in any OS. 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. A common solution is a ring bus such as the SAE-9B
>token-passing ring. Why would the communication of a rendezvous over a
>interprocessor bus between run-time systems in different kernals be any
>different than passing a message from a task to a run-time kernal
>in the same processor via system services? There are many synchronization
>problems to be reconed with in these implementations and that is why it has
>taken Ada contractors over five years to get even close to a solution.
>As an example all processors are synchronized within nanoseconds by a
>"heartbeat" signal and messages are time-tagged to resolve ambiguities between
>real-time events.

There seems to be a slight misunderstanding in some of these messages.
What is at issue--the order in which calls are issued or the order in
which call messages are sent over a network?

Using both time-tagging and network serialization of messages, the
time order of messages may still NOT be the same as the sending order,
especially using a token ring network.  If time-tagging is used to
resolve the order of real-time events, then the type of network used
is immaterial.  If the network is used to impose a serialization of
real-time events, there is no guarantee that the network order is
the same as the real-time order of occurrence.

Nevertheless, this skirts a more fundamental issue, namely that software
which depends on such implementation characteristics cannot be portable.
Remember that a major goal of the Ada language is portability of Ada
software.

-- David
-------

Re: Answer to 'a question'

[R.A. Agnew]

In article <12332478709.9.ROSENBLUM@Sierra.Stanford.EDU> ROSENBLUM@SIERRA.STANFORD.EDU (David S. Rosenblum) writes:
>
>Nevertheless, this skirts a more fundamental issue, namely that software
>which depends on such implementation characteristics cannot be portable.
>Remember that a major goal of the Ada language is portability of Ada
>software.
>
This is due to the fact that the Ada standard was not written to accomodate
multi-processor systems and it was not intended to run under an operating 
system. These facts reinforce my opinion that either the "green" proposal
was not responsive to the RFP or (as usual) neither the DOD or "green"
understood what was required of real-time imbedded systems in the 
1990-2010 time frame. When we have to bandage the mess that ADAJPO has
procurred to make it work, you can be sure that it will be non-portable.

	My opinion only.