Re: D.10

[Robert A Duff <bobduff@world.std.com>]

Robert Dewar <robert_dewar@my-dejanews.com> writes:

> My advice is to stay completely away from this feature
> in the language. It is gratutious nonsense if you ask
> me. It consists of one particular, not very well thought
> out second level primitive.
> 
> Much better to define your own.

That kind of statement would have more credibility if you gave some
reasons.  ;-)

My experience is just the opposite:

Averstar's Ada run-time system is fundamentally based on suspension
objects as the main means of suspending tasks.  We can't "define our
own" in terms of protected objects, because we're *implementing*
protected objects.  Suspension objects are a lower-level primitive.

I find suspension objects to be quite a clean feature to use;
race conditions are more easily eliminated than with (for example)
a Suspend_Self/Resume_Other pair of operations.

I know of one customer that uses suspension objects, for example, to
communicate between interrupt handlers and tasks in a way that is more
efficient than protected objects.  The key to the efficiency is that
there can never be more than one task waiting.  I don't think it's
feasible to make the compiler automatically optimize a normal protected
object in a similar way, because how is it supposed to know about this
special (rather global) property.  (Well, I suppose you could have a
pragma.)

> Possibly your implementation might do something specially
> efficient with this package, it might also do something
> specially efficient with simple cases of protected records.

I don't see how a compiler can be expected to figure out that only one
task will ever suspend on a given protected entry.  The programmer has
to tell the compiler.  Using suspension objects does that.  I can
imagine other mechanisms for telling the compiler, but I can't imagine a
totally automatic optimization along these lines.

> 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 :-)

Perhaps GNAT isn't used so much in the same sort of real-time embedded
systems where this kind of efficiency issue is so important, and perhaps
that's why your customers don't use it.  Or perhaps they don't use it
because you haven't implemented it efficiently -- the language design
can make optimizations feasible, but it can't force implementers to do
them.  If we're talking about implementing Ada on top of a typical
operating-system threads implementation, then efficiency is hopeless
anyway, so of course folks aren't going to be worrying about suspension
objects.

- Bob

P.S. The following section, D.11, Asynchronous Task Control -- now
*that's* gratuitous nonsense.  ;-)
-- 
Change robert to bob to get my real email address.  Sorry.