deallocation tasks

deallocation tasks

[Alfred Hilscher]

Hi,

does anyone have a proposal for the following problem ?

What I want do is this: I have a loop that reads input and processes it.
If the input is something that would require long runtime, I want create
a new task so that it can run in background. But if the task terminates
I think I should free the (heap) memory.

My code would look someting like this:

task type t is ...

type a_t  is access t;
 
n_t : a_t;
...

loop
 -- get input

  if  -- input requires less time
  then
    -- consume it
  else -- input requires much time, start background task
    n_t := new a_t(input);  -- memory allocated here should be
deallocated after task termination
  end if;
end loop;


Any suggestions how to 'DEALLOCATE' the memory ? There can be more than
one task at a time. Any other ideas ?

Re: deallocation tasks

[Robert A Duff]

Alfred Hilscher <Alfred.Hilscher@icn.siemens.de> writes:

> What I want do is this: I have a loop that reads input and processes it.
> If the input is something that would require long runtime, I want create
> a new task so that it can run in background. But if the task terminates
> I think I should free the (heap) memory.
> 
> My code would look someting like this:
> 
> task type t is ...
> 
> type a_t  is access t;
>  
> n_t : a_t;
> ...
> 
> loop
>  -- get input
> 
>   if  -- input requires less time
>   then
>     -- consume it
>   else -- input requires much time, start background task
>     n_t := new a_t(input);  -- memory allocated here should be
> deallocated after task termination
>   end if;
> end loop;
> 
> 
> Any suggestions how to 'DEALLOCATE' the memory ? There can be more than
> one task at a time. Any other ideas ?

Read the RM rules about Unchecked_Deallocation.  If the task has no
discriminants, then it's safe to call Unchecked_Deallocation before
the task is terminated.  (Which seems strange to me.)  If it has
discriminants, then don't do that.

You can find out whether a task is terminated using 'Terminated, but
that generally requires some sort of busy waiting.

You could also consider having a single task, or a pool of several
tasks, that gets reused for each input-processing.  You probably don't
want to create 1_000_000 tasks if the input has 1_000_000 lines.

- Bob

Re: deallocation tasks

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]


Robert A Duff <bobduff@world.std.com> a �crit dans le message :
wccbt2nln7v.fsf@world.std.com...
>
> Read the RM rules about Unchecked_Deallocation.  If the task has no
> discriminants, then it's safe to call Unchecked_Deallocation before
> the task is terminated.  (Which seems strange to me.)  If it has
> discriminants, then don't do that.

I'am not sure to understand the point here! Why is it not safe to call
Unchecked_Deallocation on a task with discriminants ?

Pascal.

--

--|------------------------------------------------------------
--| Pascal Obry                               Team-Ada Member |
--|                                                           |
--| EDF-DER-IPN-SID- T T I                                    |
--|                       Intranet: http://cln46gb            |
--| Bureau N-023            e-mail: p.obry@der.edf.fr         |
--| 1 Av G�n�ral de Gaulle  voice : +33-1-47.65.50.91         |
--| 92141 Clamart CEDEX     fax   : +33-1-47.65.50.07         |
--| FRANCE                                                    |
--|------------------------------------------------------------
--|
--|         http://perso.wanadoo.fr/pascal.obry
--|
--|   "The best way to travel is by means of imagination"

Re: deallocation tasks

[Robert A Duff]

"Pascal Obry" <p.obry@der.edf.fr> writes:

> I'am not sure to understand the point here! Why is it not safe to call
> Unchecked_Deallocation on a task with discriminants ?

In a typical implementation, a task object is represented as a chunk
of memory containing the discriminants, plus a pointer to a Task Control
Block (TCB).  When U_D is called, that chunk of memory is deallocated,
but the TCB remains, and the task keeps running.  If there are no
discrims, the task is happy.  But if there are discrims, and the task
itself refers to them, they're gone -- the task is referring to a
nonexistent object, which is a Bad Thing.

Aside: In the no-discrims case, a task object is just a pointer to the
TCB.  So an access-to-task object is a pointer to a pointer to a TCB.
However, because task types are limited, the implementation can optimize
away one level of indirection -- it can implement an access-to-task
exactly as a task object.

Other implementations are possible.  In Ada 95 (but not Ada 83), a task
object could contain the TCB, rather than a pointer to it.

- Bob

Re: deallocation tasks

[Alfred Hilscher]

Robert A Duff wrote:
> 
> - Bob

Thanks for your answer.

Alfred