Re: task synchronization and activation

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

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Evangelista Sami a �crit :
> > Hello all
> > Why does a task have to wait that all the tasks it created are
> > activated before
> > executing? I am thinking of point 9.2.5 of the RM :
> > "The task that created the new tasks and initiated their activations
> > (the activator) is blocked until all of these activations complete
> > (successfully or not)."
> > I can understand that a master has to wait for the tasks he created
> > before finalizing since in the other case it could "free" some memory
> > needed by its children.
> > But i cannot see why this synchronisation after activation is
> > necessary. What is the technical reason?
> >
> It has to do with exceptions at elaboration.
> 
> When a task is started, it first elaborates its declarative part. If
> exceptions are raised during this elaboration, they cannot be handled by
> the task itself, therefore it is necessary to notify *someone*, and the
> obvious "someone" is the activator. However, we don't want to have
> asynchronous exceptions, therefore the activator has to wait that all
> subtasks are (correctly) activated.

I can believe that that was the reasoning of the Ada 83 designers.
But I still don't quite agree with it.

For one thing, if you want to handle exceptions in the decl part,
just change this:

    task body T is
        ... -- possible exception here?
    begin
        ...
    end T;

to this:

    task body T is
    begin
        declare
            ... -- possible exception here?
        begin
            ...
        end;
    exception
        ...
    end T;

and now the task can handle it (because it's no longer in the task's
declarative part).  So it's a case of "Doctor, it hurts when I...."
"So don't do that."  ;-)

For another thing, what about exceptions in the exception handler part
of a task?  Those can't be handled by the task either, so they get
dropped on the floor -- nobody gets notified.  And in this case,
there is no 100% reliable workaround -- you can wrap that handler
in another block statement with another handler, but then what about
the 'nother handler?  There's an infinite regress.  You could carefully
inspect the outermost handler of a task, and make sure it doesn't have
any bugs (good idea!) -- but it could still get Storage_Error.

- Bob