Re: Delayed deallocation of non-terminated task in Gnat?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 30 Aug 2011 21:57:54 +0300, Niklas Holsti wrote:

> Dmitry A. Kazakov wrote:
>> On Tue, 30 Aug 2011 08:38:52 -0700 (PDT), Adam Beneschan wrote:
>> 
>>>  I'm having a bit of difficulty figuring out from
>>> the RM what the exact semantics of finalizing an unterminated task
>>> object are, but I'm pretty sure that aborting the task is not one of
>>> them.  (Note that this applies only to tasks without discriminants.
>>> If the task has discriminants, freeing it is an
>>> error---13.11.2(11ff).)
>> 
>> What is the difference? Is it an attempt to have freed tasks running
>> further? Or an attempt to construct a race condition, e.g. when the task
>> being freed has an open terminate alternative or else has been accepted a
>> rendezvous and now is going down? 
> 
> I assume that by "it" above, Dmitry is referring to the AdaCore notice 
> about a change in the way Unchecked_Deallocation works in on tasks in 
> GNAT, as quoted by Marc in his original post:

No, I meant the rationale behind ARM 13.11.2(11), which looks dubious to
me.

> "If Unchecked_Deallocation is called on a non-terminated task (which was 
> previously a no-op), the task is now marked to be freed automatically 
> when it terminates."
> 
> It seems to me that the new behaviour is more useful than the old behaviour.

Maybe. But it is unclear if it is consistent with the expectations of a
naive user. Which is: Unchecked_Deallocation awaits for the task
termination and then frees whatever memory the task is using.

>> Considering this standard pattern:
>> 
>> type Object;
>> task type Worker (Self : not null access Object'Class) is
>>    entry Shut_Down;
>> end Worker;
>> type Worker_Ptr is access Worker;
>> type Object is new Ada.Finalization.Limited_Controlled with record
>>    Worker : Worker_Ptr;
>> end Object;
>> overriding procedure Finalize (This : in out Object);
> 
> (I don't think that the use of a controlled type is central to the 
> example. Am I wrong, Dmitry?)

It is the most common case when a task has a discriminant. Since task as a
component is a non-starter, the only work-around would be a controlled type
removing its access-to-task component from Finalize.

>> Now the following is a race with a bounded error:
> 
> As I understand it, there was a race under the old behaviour, but not 
> under the new behaviour.

Well, it could be read as if the choice offered by ARM 13.11.2(12) was
taken. Though according to ARM, it is still a bounded error, and maybe even
worse than that (see the scenario below).

>> procedure Finalize (This : in out Object) is
>>    procedure Free is new Ada.Unchecked_Deallocation (...);
>> begin
>>    if This.Worker /= null then
>>       This.Worker.Shut_Down;
>>       Free (This.Worker);
> 
> With the old behaviour of Unchecked_Deallocation, the effect of this 
> Free call depended on the state of This.Worker: if the task was not yet 
> terminated, Free had no effect; if the task was terminated, Free 
> deallocated the task object.
> 
> With the new behaviour, the task object is always deallocated, either by 
>   the Free call (if the task is already terminated at that time) or by 
> the RTS when the task terminates later, after the Free call.

This is unclear. Because if Free is not blocked, the Object's Finalize
continues, possibly ends (and then the object is freed), while the task is
still running and possibly accessing the object through its discriminant.
This kind of error is unbounded in contradiction to ARM 13.11.2(11). It
would be rather catastrophic behavior.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de