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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fc232b1f37897ed0 X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: D.10 Date: 1999/04/13 Message-ID: <3713BDBF.53855B6C@averstar.com>#1/1 X-Deja-AN: 466055715 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <7evc8l$pde$1@nnrp1.dejanews.com> Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-04-13T00:00:00+00:00 List-Id: Matthew Heaney wrote: > ... > The rationale makes the argument that a suspension object is likely to > be more efficient because it is "unnecessary to maintain a queue -- a > major saving in run-time cost." (Rat95 D.10 p. D-37 para. 6) > > > Certainly GNAT just translates this into the corresponding > > protected type in a naive way, and we have never seen a > > program that used it except an ACVC test or two :-) > > I learned about suspension objects from the keynote speaker at last > year's SIGAda conference, a person (I forget his name; works for Aonix > UK) involved in the formulation of the Ravenscar profile. > > He said specifically that this was a feature for "close to the metal > programming", a phrase he learnt from none other than Tucker Taft. > > You might think that a suspension object is "gratuitous nonsense," and > of course you are entitled to your opinion. > > However, my expectation is that the suspension object is in the language > because it admits a more efficient implementation than using a entry > queue. > > For example, the programmer might be writing a program using an entry > queue that he knows will only have a maximum of one caller. In this > case, a queue is unnecessary. > > But let us waive aside any debates about whether a suspension object is > a useful language feature, and concentrate on specifics. Is the program > in section 12.3.1 of Burns and Wellings correct, or not? I will admit that when designing the feature, we did not consider the paradigm which Burns and Welling now suggest. However, that always happens when you design a feature. Users find new and interesting uses for it that the designers never anticipated. This certainly doesn't automatically imply that the usage is bad, just unanticipated. As far as whether the RM guarantees that the result of such a use is well-defined, it seems it makes no guarantees about atomicity between one task calling suspend_until_true and another doing the same. (Although Robert Dewar objects to the use of the term "atomic with respect to one another," I believe the intent is fairly clear -- no bad race conditions exist, and two tasks may safely call the operations concurrently.) Now that this apparently useful paradigm has been identified by B & W, it might be worth requiring that it be well-defined. I suspect that most existing implementations will already support it, though some investigation would obviously be worthwhile. Do you have any reason to believe it isn't currently supported by all implementations? One other comment: There was quite a bit of controversy when the synchronous and asynchronous task control features were first proposed. Ultimately, we decided to put them in the Real-Time Annex, but we intended that their semantics be explainable in terms of other (albeit higher-level) features. In fact, the async task control was explained in terms of priority change. We considered explaining sync task control in terms of protected objects, but eventually decided to define them on their own, though the intent was that they be as well defined as protected objects. Burns and Wellings have illustrated that we forgot to consider the race between one Suspend-Until-True and another, when you "know" that the suspension object is initially True. Clearly if it might be initially False, then the race is not of great interest, because Program_Error is going to be raised in one of them. The ARG should take a position on what happens when there is such a race. I don't see any reason not to require well-defined semantics in this case as well. I don't see a significant implementation burden. -Tuck -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA