Re: Finalization of a record containing a task

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Craig Carey <research@ijs.co.nz> writes:

> On 16 Feb 2005 17:08:30 -0500, Robert A Duff wrote:
> > [...] but you can't mix delay alternatives with
> >terminate alternatives.
> ...
> >You also can't mix entry calls with terminate alternatives, so if the
> >task wants to talk to a protected object, you're stuck.
> ...
> 
> Are all those restrictions on select statements actually important to the
>  language implementors ?.
> 
> The current design of select statement seems to be identical to the
>  c. 1982 design. Perhaps a redesign could occur.

From a practical point of view: it's unlikely that any such redesign
will happen any time soon.  The feature set for Ada 2005 is pretty much
closed.  Who knows what the situation will be in 2015?

But it's an interesting question, which I've thought a lot about in the
past.  It's not such much an ease of implementation issue.  The question
is whether the semantics can make sense.

At a high level, "terminate" means, roughly, "if there's no possibility
that I can wake up again, then terminate me."

The Ada 83 rules are constructed so that if all tasks dependent upon a
given master are either terminated or waiting on an open terminate
alternative, then none of them can possibly wake up, so it's safe
to terminate them all.  (One exception: an interrupt could wake them
up, which Ada 83 handles by saying "implementation defined" -- something
of a copout.)

This is based on the fact that tasks can only accept their own entries,
and the fact that you can't call a task's entries without being inside
its master.  (Interrupts can come in from out of the blue.)

But if we allowed:

    select
        X.Some_Entry(...);
    or
        terminate;
    end select;

then X could outlive this task.  So how do we know when it's safe to
terminate this task?  I'd be interested in hearing any ideas -- it seems
like it could be a useful capability, if the rules could make sense!

X could be a task or a protected object.  Requeue makes it even more
"interesting".  ;-)  Imagine the call being requeued here, there,
and elsewhere, unbeknownst to the caller.

I think a delay statement is similar to an entry call -- you can think
of it as a call on a protected object's entry, such that the barrier
will become true at some time.  So if the problem can be solved for
entry calls, it can be solved for delay alternatives.

----

Note that it was proposed during Ada 9X to allow multiple entry calls,
as in:

    select
        X.Some_Entry(...);
    or
        Y.Some_Other_Entry(...); -- illegal!
    end select;

which would mean pick whichever entry call becomes ready first
(similar to the multiple accept case).
Sadly, that didn't make it into Ada 95 (nor Ada 2005).
I don't know of any semantic anomalies; I think it was just
considered too hard to implement.

- Bob