Re: Composing tasks and protected objects

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcchde4dyv4.fsf@shell01.TheWorld.com...
> Florian Weimer <fw@deneb.enyo.de> writes:
>
> > * Robert A. Duff:
> > > The multi-way call feature was rejected primarily due to perceived
> > > difficulty of implementation, or perceived difficulty of *efficient*
> > > implementation.  I did not agree with that argument.
> >
> > I could understand that argument if this language feature caused
> > uniform overhead on all protected operations, even if it isn't used
> > anywhere in the program.  Is this really the case?
>
> I think I could implement multi-ways calls in such a way that there is
> zero or near-zero overhead for the currently-allowed features (plain
> calls, timed/conditional calls).  But I have not proven that by doing
> so!

The UI teams of the Ada 9X effort were asked to write reports on this
feature. None of them came up with an efficient implementation. Their
reports are still around somewhere (use the search engine to look in the
AdaIC archives - archive.adaic.com).

> Inefficiency is never a good reason to leave a feature out of a
> language.  What matters is distributed overhead (i.e. when a feature
> causes inefficiency when you *don't* use it).

I think that most of the possible efficient implementations did so by having
distributed overhead. But it was a long, long time ago, so I don't remember
the details anymore.

But I do remember that one of the major issues was that the people who were
pushing for the feature were hard-real-time types with strict timing
requirements. No one had an implementation that could meet those sorts of
requirements (polling seemed to be required). Having a feature that cannot
be efficicient enough for the customers is silly.

> There's also the issue that the implementation experiments done during
> the Ada 9X process were done on *existing* implementations, which were
> designed with the requirements of Ada 83 in mind.  Adding a feature to
> an existing implementation is sometimes a lot harder than implementing
> it in a from-scratch design where the designer knows the requirements

Possibly. I have to wonder if there wouldn't be too many conflicting
requirements to make that possible. The "Bob" language without task entries
would clearly make it easier to allow other sorts of things (although I
can't quite figure out how it would work). A clear sheet of paper helps
things in every dimension -- but that isn't going to happen for Ada, as
compatibility is important.

                                Randy.