Re: Deallocating records with task type fields.

["Jeffrey R. Carter" <spam@spam.com>]

Gene wrote:
> Please consider these declarations for a task with some task local
> data:
> 
>    type Listener_Type;
> 
>    task type Listener_Task_Type(Env : access Listener_Type);
> 
>    type Listener_Type is
>       record
>          Port : Positive;
>          Executive : Listener_Task_Type(Listener_Type'Access);
>       end record;
> 
> With this, the executive task has access to the task local environment
> exemplified here by a port number.
> 
> Here are the questions:
> 
> 1.  Is this a good idiom for implementing task local data, or is there
> some other preferable method?

For a case like this, I'd probably suggest

task type Listener (Port : Positive);

More generally, how do you create an object of Listener_Type and ensure that you 
assign a value to its Port component before its Executive accesses that component?

An alternative is to not embed the task in its data:

task type T (Environment : access Environment_Data);

This requires that you have the data available when you create the task object.

> 2.  As I read the ALRM it is incorrect to deallocate a Listener_Type
> object until the Executive task has exited.  What is a good idiomatic
> way for the Executive to deallocate its own task local storage just
> before it exits and without causing a race condition?  [The only ways I
> can come up with seem like excessive machinery.]

The best way is not to use allocation, and thus not need deallocation.

If you do need to allocate the data, you can use the access type for that 
instead of an anonymous access type:

task type T (Environment : Data_Ptr);

and the task could make a copy of Environment and deallocate that. I would not 
generally advise such an approach.

-- 
Jeff Carter
"I like it when the support group complains that they have
insufficient data on mean time to repair bugs in Ada software."
Robert I. Eachus
91