Tasks unleashed

Tasks unleashed

[Jano]

Hello again,

now my question is referred to the use of task types through access 
types.

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.

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. 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)

*) 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.

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.

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?

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Tasks unleashed

[Stephen Leake]

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.
> <snip>
> 
> In any case, the memory thing forces to use pools of reusable tasks, 
> it's my main and crucial conclusion.

Yes, this is the recommended approach. It's faster, also.

-- 
-- Stephe

Re: Tasks unleashed

[Robert A Duff]

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

Re: Tasks unleashed

[Jano]

Robert A Duff dice...

> 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?

Increasingly consumed memory. I have put a 0.1 delay.

> > What things could arise from that?
> 
> Bad things.  ;-)

I'm doomed... XD

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Tasks unleashed

[tmoran]

>In any case, the memory thing forces to use pools of reusable tasks,
>it's my main and crucial conclusion.

  Have you considered a protected Buffer of work to do and a fixed pool of
tasks which queue on an entry waiting for the Buffer to have some work to
do (or instructions to quit)?  Then you needn't create or destroy the
worker tasks.

Re: Tasks unleashed

[Jano]

tmoran@acm.org dice...
> >In any case, the memory thing forces to use pools of reusable tasks,
> >it's my main and crucial conclusion.
> 
>   Have you considered a protected Buffer of work to do and a fixed pool of
> tasks which queue on an entry waiting for the Buffer to have some work to
> do (or instructions to quit)?  Then you needn't create or destroy the
> worker tasks.

That's exactly what I'm doing :) but sometimes the "fixed" compromise 
bugs me. ITOH, normally is better to have a upper bound for things, I 
think.

-- 
-------------------------
Jano
402450.at.cepsz.unizar.es
-------------------------

Re: Tasks unleashed

[tmoran]

> >   Have you considered a protected Buffer of work to do and a fixed pool of
> > tasks which queue on an entry waiting for the Buffer to have some work to
> > ...
> That's exactly what I'm doing :) but sometimes the "fixed" compromise
> bugs me. ITOH, normally is better to have a upper bound for things, I
> think.

  You could make a hybrid.  An array of (initially null) pointers to
tasks, and, if Buffers can't service a client in a reasonable length of
time, you start up a "new" task.  Then your fixed limit is buffer'length +
task_array'length, but if the program actually only needs a few tasks, or
is sufficiently patient, you will only start up a small number of tasks.
Of course if your program desperately needs a large number of tasks early
in execution, but not later, you'll have to depend on virtual memory to
move those, now superfluous, tasks out of RAM.  If the program really has
phases like that, perhaps it should be split into two programs to be run
sequentially.

Re: Tasks unleashed

[Craig Carey]

On Fri, 2 May 2003 13:21:13 +0200, Jano <nono@celes.unizar.es> wrote:

>tmoran@acm.org dice...
>> >In any case, the memory thing forces to use pools of reusable tasks,
>> >it's my main and crucial conclusion.
>> 
>>   Have you considered a protected Buffer of work to do and a fixed pool of
>> tasks which queue on an entry waiting for the Buffer to have some work to
>> do (or instructions to quit)?  Then you needn't create or destroy the
>> worker tasks.
>
>That's exactly what I'm doing :) but sometimes the "fixed" compromise 
>bugs me. ITOH, normally is better to have a upper bound for things, I 
>think.


The problem of Ada tasks leaking memory, is 100% absent if the program is
written well enough and either of the 2 compilers named here, are used (in
Windows).

Recovering the memory of a task silently fails if the task was not
 finished.

** Test 1: the memory leak is completely absent:
   for K in 1 .. 20_000 loop  -- N=20,000
      X := new A.Tt;
      N := N + 1;
      X.The_End;
      delay 1.0E-30;    --  [1]
      Free (X);         --  [2]
   end loop;

ObjectAda: 596K for both N=1,000 and N=200,000
GNAT 3.15: 760K, for both N=1,000 and N=200,000

1024 / 200,000 < 1, so no memory was being leaked for each deallocated
 task (in Windows 2000, OA 7.2.2, GNAT 3.15p).

** Test 2: Lines "[1]" and "[2]" are swapped. Now the large memory leak of
the test program is confirmed.

ObjectAda: 47.8MB, N=20,000
GNAT 3.15: 20.7MB, N=20,000,  "-largs --stack=0x40000,0x8000".


Craig Carey ; Ada 95 mailing lists htp://www.ijs.co.nz/ada_95.htm

Re: Tasks unleashed

[Pascal Obry]

Craig Carey <research@ijs.co.nz> writes:

> Recovering the memory of a task silently fails if the task was not
>  finished.
> 
> ** Test 1: the memory leak is completely absent:
>    for K in 1 .. 20_000 loop  -- N=20,000
>       X := new A.Tt;
>       N := N + 1;
>       X.The_End;
>       delay 1.0E-30;    --  [1]
>       Free (X);         --  [2]
>    end loop;

[1] is not right here. The delay could still not be enough. What I usually do
is loop until 'Terminated is true.

Something like: (not compiled)

    for K in 1 .. 20_000 loop  -- N=20,000
       X := new A.Tt;
       N := N + 1;
       X.The_End;

       loop
          exit when X'Terminated;
          delay 1.0E-30;    --  [1]
       end loop;

       Free (X);         --  [2]
    end loop;     

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595