Re: Query about monitor (passive) task optimization

[ddciiny!jls@uunet.uu.net (Jonathan Schilling)]

In article <1993Aug2.064113.938@celsiustech.se> bjkae@celsiustech.se (Bjorn Kal
lberg) writes:
>In article <CB403J.74M@ddciiny.UUCP> jls@ddciiny.UUCP (Jonathan
>Schilling) writes:
>
>>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?  
>
>I thought a Real Time program was a program, where timing was an essential
>part of the semantics. Thus, semantics is changed.
>
>>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.
>
>Or suddenly slower, when you change the program in some little way, so
>the compiler can not apply the optimization any longer, that it previously did
.
>And you do not get a warning or error, which you will if you have explicitly
>told the compiler, that this must be a passive task.

These are valid points, but they extend to virtually every language feature
in Ada, not just synchronization tasks.  For instance, changing one of the
bounds of an array type declaration from a static to a dynamic value could 
well result in *much* more code being generated for object declarations and
operations of that type.  Yet most compilers that I know of will not issue 
a warning when this happens, nor have a pragma to explicitly "control" it.

The essence of compiler optimization in Ada is recognizing simple instances
of potentially complex constructs, and generating only the code appropriate
for the simple case.  This goes on all the time in Ada, with array types,
record types, discriminants, slices, type conversions, tasks, representation
clauses, and so on.  While compiler user documentation may attempt to outline
what construct usages the compiler will see as "simple", the coverage is
rarely complete.  Users often stumble across minor source changes that
produce significant differences in object efficiency, for reasons that are
understandable to the compiler writers but less so to anyone else.

Unless someone wants to change Ada, or create another real-time language,
such that the language specification itself imposes execution-time
efficiency requirements on every construct in the language (has anyone 
ever tried this?), I'm not convinced of the usefulness of giving special
treatment to the monitor task optimization.


-- 
Jonathan Schilling
DDC-I, Inc.
uunet!ddciiny!jls