Re: Query about monitor (passive) task optimization

[europa.eng.gtefsd.com!fs7.ece.cmu.edu!news.sei.cmu.edu!ae@uunet.uu.net ( Arthur Evans)]

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