Re: Finalization of library level tasks

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pbs4km$doq$1@gioia.aioe.org...
> On 26/04/2018 01:46, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:pavqa6$1qdj$1@gioia.aioe.org...
>> ...
>>> Yes. The problem is the order of finalization. For some unclear reason 
>>> the
>>> task's access type is attempted before the object that contains that
>>> access type because they are in the same scope.
>>
>> It's not unclear - tasks have to terminate before objects are finalized 
>> so
>> that the tasks aren't trying to use finalized objects. If the object is a
>> protected object, that could be a really bad deal (remember that 
>> finalizing
>> a protected object raises tasking error in any queued task and prevents
>> future calls).
>
> It is all objects, not just ones containing the task. You could have:
>
>    package A is
>       task type Foo ...
>       X : Foo;
>    end A;
>
>    package A.B is
>       type Bar is new Ada.Finalization.Controlled ...
>       Y : Bar;
>    end A.B;
>
> Even so, finalization of Y will await termination of X!

It has to. There is no way for the compiler to know that there is no way for 
X to access Y.

> The deadlock in the RM is constructed to prevent any possible way to break 
> it.

Correct, and that is by design. An unbreakable premise of Ada is that 
finalization of objects will always be done no matter what happens. That's 
why subpools have a finalization mechanism, Unchecked_Deallocation does 
finalization, assignment does finalization, ad nauseum. The designer of an 
Ada library (ADT) can always be assured that their last wishes will be 
executed regardless of what horrors the client tries to invent. This is a 
critical property for reusability.

> There are dozens ways to fix the mess but there seems no interest at all.

Correction: there are dozens of ways to make a worse mess. There is no way 
to "fix" the issue, because any change to the rules just breaks in some 
other case. Or completely destroys the ability of ADTs to assume that 
finalization happens.

When we ran into the problem in the Claw design, I spent a lot of time 
trying to come up with a fix. I couldn't find anything that didn't have 
worse problems in some cases. I believe other ARG members did the same 
thing; the environment task solution seemed to be the best workaround (it 
works great in Claw, presuming of course that the compiler implements it 
correctly).

Claw, for instance, uses a number of locks. We had problems with compilers 
finalizing those locks before awaiting tasks, meaning that the tasks got 
Program_Error for no expected reason. (And one compiler that will remain 
nameless just crashed if you called such a lock; there's an ACATS test for 
that, too, these days.)

The critical thing from an Ada perspective is that the rules are 
well-defined and don't change from implementation-to-implementation. Then it 
is always possible to find a solution (not necessarily an easy one).

Task termination is rarely considered in Ada books, yet it is one of the 
hardest things to accomplish. I don't have any termination technique at all 
in the spam filter, because I couldn't think of anything that would actually 
work. Luckily, you can just kill the process from Windows in the few cases 
where you need to shut the thing down.

One of the advantages of the parallelism model in Ada 2020 is that you don't 
have to write explicit tasks so you don't have to deal with termination of 
them.

                          Randy.