Re: Freeing access-to-task objects

["Björn Lundin" <bnl@nowhere.com>]

On 2022-10-01 13:58, Dmitry A. Kazakov wrote:
> On 2022-10-01 13:40, J-P. Rosen wrote:
>> Le 30/09/2022 à 12:16, Emmanuel Briot a écrit :
>>> Please find a new blog post at:
>>>
>>> https://deepbluecap.com/freeing-task-access-objects/
>>>
>>> Abstract:
>>> Freeing Ada tasks could result in accessing freed memory. This post 
>>> describes the proper way of freeing access-to-task objects.
>>
>> I don't like an active loop to wait for task termination.
> 
> IMO, it is the best method.
> 

I agree, in practice it works very well, at least for our system.
When ported to GNAT in 2003 I used this pattern.

We use it in IPC, where main makes a blocking call to a PO,
looking for incoming messages. The PO is protecting a list,
and main blocks on list_count = 0.

Another task (receive task) in the IPC body blocks on a read call from a 
named pipe.
When a message arrives in the pipe, this task is putting it into the 
PO's list.

Main then unblocks, since list_count >0, gets the message and treats it,

But since the receiver task is blocking as well, it is difficult to make
that call timeout. Sometimes we want main to actually block until a 
message arrives, but sometimes we'd like to timeout after a minute or so.

Main can call the receive procedure with or without a timeout.

If time is used in the call, a third task is started - with new - with a 
timeout time, and a 'stop' entry. This timer task just delays timeout 
time, and writes a timeout message to the pipe when expired - thus 
releasing the blocking task, and also releasing main since a timeout 
message was put in PO's list and list_count becomes > 0.

If a message is put by another process in the pipe, the receiving task 
calls stop on the timer task, removes any timeout messages in the list 
if we had a race, and puts the message in the list.

Here we also loop over the timer task until terminated.

Worked very well for many years in many installations

We do send messages frequently. in bursts up to 100 msgs/s
but average is less likely than 10 msgs/s


1_000_000 msgs/day is not unusual, so memleaks here is a problem


-- 
/Björn