Re: Class with task destructor

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ey516bovprzb$.1tjszfc528chj$.dlg@40tude.net...
> On Tue, 29 Nov 2011 18:21:51 -0800 (PST), Adam Beneschan wrote:
...
>> I don't know of a good way
>> around this (besides Ada.Task_Termination).
>
> I am using polling for T'Terminated after the rendezvous.

That's the Ada 83 solution, and there really isn't anything better in the 
language. Not sure if there even could be (I'm not a top-level expert on 
real-time issues, beyond what the Janus/Ada runtime does).

...
> Not a feature, rather a plain language design bug. Unchecked_Deallocation
> shall wait for the object's finalization. Finalization of a task evidently
> includes its termination. So Unchecked_Deallocation must block until
> termination before it frees anything.

The problem here is that finalization and task termination are different 
operations according to the language, and task termination generally has to 
be done first. This was done, I believe, so that any running task does not 
have to worry about having the objects it accesses finalized.

I usually agree that this is wrong, but actually it doesn't matter what 
choice is made -- any choice will be wrong a large part of the time. The 
current choice, for instance, makes it possible for finalize routines to 
access objects that have already been finalized (and allocate objects of 
access types that already have been finalized) - a finalize routine often 
needs to protect against this if it needs to access anything outside of the 
object being finalized.

We had a lot of trouble with this in Claw, particularly because we wanted to 
use a global finalizable object to tell the library tasks when to terminate. 
But that doesn't work in Ada, because tasks are awaited before any 
library-level finalization is done -- and thus the tasks never get their 
shutdown entries called. We eventually found a tricky way to use 
Ada.Task_Identification to determine when the main subprogram has exited, 
and used that to terminate the tasks. (And then we had to get all of the Ada 
95 compilers to implement it properly -- that took a couple of years and an 
ACATS test.)

Switching the order of task waiting and finalization would have worked in 
this case, but it wouldn't work in general as the library tasks would then 
be accessing global objects that have been finalized. Which seems worse than 
the original problem.

Point is that all of these things are interelated, and it isn't always 
possible to make all of them perfect. (Tucker Taft calls this "moving the 
bump under the carpet"; you can move it around to different locations, but 
you can't get rid of it without tearing out the carpet. That happens a lot 
more often in language design than most people think.)

                                           Randy.