Re: Composing tasks and protected objects

[Florian Weimer <fw@deneb.enyo.de>]

* Robert A. Duff:

>> In short, I want to perform protected entry calls and selective accept
>> in parallel.
>> 
>> Is this possible at all, without writing lots of stupid wrappers?
>
> No.  You cannot mix entry calls and accepts in the same select
> statement.  You can't mix entry calls with "terminate", either.

Yes, of course the code does not compile.  I thought that I might have
missed something obvious and this syntax was left out on the grounds
of orthogonality of language features or something like that.

> The original Ada 9X design proposed to allow multiple entry calls in a
> select, which would solve your main problem, which is waiting on
> multiple events.

Indeed.

> Your two entries would then become entries of a protected object,
> and the above select would call them.  Whoever calls those two
> entries would instead call protected procedures that trigger those
> entries.

Yes, this would solve the main multiplexing problem.

> 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?

> One workaround is to change the call to Get into an accept
> -- i.e. make Get be an entry of this task, and arrange for it
> to be called as appropriate.

Yes, but this only half of the story.  In order to decouple the sender
from the receiver, I think I need some access-to-entry concept.  I can
only implement this using some wrapper.

It seems that the synchronous interfaces of Ada 2005 would make this
considerably easier.

>>...If
>> not, what was the justification for not integrating the two language
>> features (protected objects/tasks) in this way?
>
> 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.

> 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?

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.