Re: Composing tasks and protected objects

[Robert A Duff <bobduff@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!

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

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.

> > As far as I know, mixing calls and accepts was not considered,
> > perhaps because protected objects were intended to be a very lightweight
> > mechanism (compared to task entries and accept statements).
> 
> Hmm.  It's still a bit strange that these language concepts are so far
> away from each other.

Well, if I were designing a language from scratch, I would have
something like protected object entries.  I would eliminate task entries
entirely, and beef up PO entries so that can do all the useful things
that task entries can do (such as waiting on multiple events).

Task entries cause an enormous amount of unnecessary complexity in the
language.  Task types and task bodies could be completely eliminated,
for example.

As I said, I'm not sure what to do about terminate alternatives.

> > I don't think terminates mixed with calls was considered, either.  It's
> > not clear what it should mean.  Normally, "terminate" means the task
> > terminates when there is no possibility that anybody might want to call
> > the entries the task is waiting on.
> 
> I think the alternative is also chosen if the master completes.
> Wouldn't this lead to useful semantics in this case as well?

A terminate alt is chosen if the master is complete, and all tasks
dependent upon that master (directly or indirectly) are terminated, or
are waiting at select-with-terminate statements.  Given these conditions
(and ignoring interrupts), the task's entries could never be called.

But the same conditions in the entry call case do not imply that the
called entry will never be triggered, because the called entry can be
essentially anywhere, without regard to scopes and whatnot.

> In the queue example, you'd give up your subscription to that queue,
> but this would be handled by a controlled object declared in the task,
> I think.

I don't understand what you mean here.

- Bob