From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS autolearn=no autolearn_force=no version=3.4.5-pre1 Date: 2 Aug 93 13:19:24 GMT From: europa.eng.gtefsd.com!fs7.ece.cmu.edu!news.sei.cmu.edu!ae@uunet.uu.net ( Arthur Evans) Subject: Re: Query about monitor (passive) task optimization Message-ID: <1993Aug2.091924.19310@sei.cmu.edu> List-Id: jls@ddciiny.UUCP (Jonathan Schilling) quotes Robert Dewar: >>Mike [Feldman] assumes that automatic recognition of passive tasks is >>a good thing. He is apparently unaware that this is by no means >>obvious, and indeed most of the Ada folks in realtime areas that I >>have talked to do not AT ALL like the idea of such automatic >>recognition, and much prefer explicit control over thread structure. Schilling replies: >I've heard of these objections before, but I don't fully understand them. >Assuming the optimization is transparent to the programmer, and does not >in any way change the semantics of the program, what "control" is being >lost? From within the program, using only standard Ada, one wouldn't >even be able to detect whether the optimization had happened or not >(this might be doable with CIFO-type interfaces, depending on the >runtime system implementation). The only difference is that the program >runs faster. mfeldman@seas.gwu.edu (Michael Feldman) replies: > Exactly. That's why I applauded DDC-I for doing it. > The reason for the objection is that people do not trust their > compilers, especially in the realtime business. > [MORE, DELETED] That's not the reason that was cited by the real-time folks in Ada 9X design discussions. Consider a real time application with tight time constraints. The programmer, who is familiar with the requirements of the vendor's compiler, codes the task with care so that the compiler will be able to perform clever optimizations. The code meets its requirements. Later, in maintenance, another programmer makes a seemingly trivial modification to the source code. An effect, unfortunately, is that the conditions for performing the optimization are no longer met. The code is still semantically correct, but the application fails in ways difficult to diagnose because a timing constraint is sometimes missed. The advantage of the pragma approach is that it precludes this possibility. Use of the pragma says, in effect, "I want the compiler to perform this optimization, and I promise to avoid certain features that preclude its use." If a change in maintenance causes the promise not to be kept, the complier can provide a clear diagnostic. Should Ada cater to the hard real-time folks as above, or to the general community that Mike speaks for? Well, yes, it should -- to both. But keep in mind that Ada's initial sponsor had in mind embedded applications, and that such applications usually have hard real-time requirements. Now, having said all that, I can agree with Mike's comment. Here it is 10 years after standardization of Ada-83. It may not be surprising that vendors first took the pragma approach; it's sad that after all this time so few have implemented the optimizations. The right approach, I would say, is to implement the optimizations _and_ provide a pragma that makes the promise that the program will meet the requirements for the optimization. Art Evans ---------------------------------------------- Arthur Evans, Jr, PhD Ada Consultant 461 Fairview Road Pittsburgh PA 15238-1933 412-963-0839 ae@sei.cmu.edu