Re: Tasks unleashed

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Jano <nono@celes.unizar.es> writes:

> I seem to remember from a distant conversation that every task allocated 
> takes a small amount of memory, amongst other things, to provide 
> satisfactory results for 'Callable attribute.

Yes, an implementation cannot reclaim all the storage for a task when it
terminates, if there is some way to name the task.  As you say,
'Callable has to return False (rather than referring to freed memory).
Similarly, an entry call must raise Tasking_Error (rather than
crashing).

However, a clever implementation can reclaim all but one word of
storage.

> Sometimes I'd like to have a task type that, when some activity is 
> needed, is created and forgotten. For example, it takes an access 
> constraint and from that point on is completely independent.
> 
> A related aspect is that I don't know if Unchecked_deallocation is to be 
> performed on tasks.

Read RM-13.11.2 (or AARM, if you want underlying reasons).  Your task
below has no discriminants, so it's OK to U_D it.

>... See the following example:
> 
> ------8<---------
> 
> with Ada.Unchecked_deallocation;
> 
> procedure test is
> 
>    task type tt is
>       entry The_end;
>    end tt;
> 
>    task body tt is
>    begin
>       accept The_end do
>          null;
>       end The_end;
>       -- delay 1.0;
>    end tt;
> 
>    type att is access all tt;
> 
>    x : att;
> 
>    procedure Free is new Ada.Unchecked_deallocation (tt, att);
> 
> begin
>    loop		-- for N in 1 .. 100 loop
>       x := new tt;
>       x.The_end;
>       Free (x);
>    end loop;
> end;
> 
> ------8<---------
> 
> It illustrates various points that come to my mind:
> 
> *) It eats quickly all my memory (Gnat 3.15p)

The RM has no requirements about freeing memory.  13.11.2(17) is
"Implementation Advice", not because it's unimportant, but because we
didn't know how to formalize it.

Nonetheless, I would consider it a bug to fail to free a task that is
both terminated and U_D'ed.  What happens if you put a "delay" in the
loop?

> *) You can't be sure that the task is terminated when free is tried (and 
> no exception is raised in that case).
> 
> *) Free seems to do nothing (gnatmem reports 0 deallocations using a 
> closed loop of 100 iterations).
> 
> In any case, the memory thing forces to use pools of reusable tasks, 
> it's my main and crucial conclusion.

That may be more efficient on some systems (if creating and destroying
tasks is slow, perhaps because it does system calls), but you shouldn't
*have* to do that, IMHO.  On one of our (SofCheck's) embedded targets,
we use that method internally anyway, so it wouldn't make much speed
difference.

> Even if Free for tasks were not to free resources, it seems reasonable 
> that it could instruct the runtime that that task will not be referenced 
> again, so it should leave a 0 memory footprint after termination? But 
> now I'm making things up, I can't find right now specific comments in 
> the ARM about task access types.

Yes, I think Free for a non-terminated task should mark the task as
freed, so storage gets reclaimed on termination.  But there is no such
formal requirement in the RM.  How could there be?

> Could someone comment on these things? Behave differently other 
> compilers? I'm a fool to try these things or simply an ignorant?
> 
> I should say that I have an innate instinct to try to resolve things the 
> way others see distinctly are not to be tried :)
> 
> Now that there is an ongoing discussion about people not knowing Ada 
> using it for large new developments, think about it: I have some fair 
> experience, several years of exposure (but only one fairly sized project 
> behind me), and I'm still trying these twisted things. What could do a 
> complete ignorant :) My other glorious idea yesterday was to free a 
> protected type from inside one of its own procedures. I did it, but 
> decided not to carry on (nothing seemed immediately wrong, though)... 
> What things could arise from that?

Bad things.  ;-)

- Bob