8440425@wwu.EDU (Richard Golding) (09/12/87)
"... 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.eduhyland@esosun.UUCP (Steve Hyland) (09/23/87)
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