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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 2 Aug 93 18:13:19 GMT
From: seas.gwu.edu!mfeldman@uunet.uu.net  (Michael Feldman)
Subject: Re: Query about monitor (passive) task optimization
Message-ID: <1993Aug2.181319.18960@seas.gwu.edu>
List-Id: <comp.lang.ada>

In article <1993Aug2.091924.19310@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) wr
ites:
>
>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.

I would assert that it is really not too hard to understand what a
passive task is. Turning a passive task into something else is NOT
a "seemingly trivial change", except maybe to a programmer who is
clueless about what concurrency's all about. (Maybe that is part of
the problem: clueless programmers?)
>
>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.

If 1815-A had required this pragma, I would have no objection. (Well,
I'd rather it be automatic, but a pragma is a decent mechanism for
optimization, used all over Ada for this sort of thing.) But under the
circumstances, it's implementation-dependent. So much for a common
language with reasonably portable program behavior.
>
>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.

All the more reason for passive tasks being identified as such in the
LRM, maybe by pragma. Fine. Or all the major vendors could agree on
a de facto standard pragma PASSIVE, with the same qualifiying conditions.
Fine. But what we've got now is a sort of feature war, which is not what
Ada was supposed to be about.

It is instructive to read the Rationale again on this subject, and maybe
the LRM. There tasking is discussed as a _language_ feature, an abstraction
mechanism. Two assumptions are implicit: (1) users would take the trouble
to understand the feature, and (2) compiler writers would (learn how to)
implement it with increasing efficiency and sophistication in each new
release. That's not what we got, is it?
>
>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.
>
Well, OK. I suppose we need a "pragma NO_SIDE_EFFECTS" for each arithmetic
expression we want the compiler to optimize. :-)

Seriously - my point is that Ada compiler houses have been IMHO market
trend-followers, instead of trend-setters. These guys are (were supposed to 
be) the Best and the Brightest: young, well-educated, enthusiastic, and
working with a rich language that really exercised their minds. From the
private mail I get from current and former techies in these companies,
I'm getting the picture that there are a lot of frustrated techies
out there, stifled by myopic management looking mainly at the next
contract or the next quarter instead of the next decade. It all comes
down to short-term return-on-investment, doesn't it?

Sigh...

Mike