Re: D.10

[Tucker Taft <stt@averstar.com>]

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