Alfred.Peterson@sei.cmu.EDU.UUCP (08/27/87)
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>
young@cxsea.UUCP (Gary Young) (09/02/87)
|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"?
agnew@trwrc.UUCP (R.A. Agnew) (09/04/87)
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 **************
ROSENBLUM@SIERRA.STANFORD.EDU (David S. Rosenblum) (09/06/87)
>>>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 -------
agnew@trwrc.UUCP (R.A. Agnew) (09/11/87)
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.