* deallocation tasks
@ 2000-05-03 0:00 Alfred Hilscher
2000-05-03 0:00 ` Robert A Duff
0 siblings, 1 reply; 5+ messages in thread
From: Alfred Hilscher @ 2000-05-03 0:00 UTC (permalink / raw)
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 ?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: deallocation tasks
2000-05-03 0:00 deallocation tasks Alfred Hilscher
@ 2000-05-03 0:00 ` Robert A Duff
2000-05-04 0:00 ` Pascal Obry
0 siblings, 1 reply; 5+ messages in thread
From: Robert A Duff @ 2000-05-03 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: deallocation tasks
2000-05-03 0:00 ` Robert A Duff
@ 2000-05-04 0:00 ` Pascal Obry
2000-05-04 0:00 ` Robert A Duff
0 siblings, 1 reply; 5+ messages in thread
From: Pascal Obry @ 2000-05-04 0:00 UTC (permalink / raw)
[-- 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"
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: deallocation tasks
2000-05-04 0:00 ` Pascal Obry
@ 2000-05-04 0:00 ` Robert A Duff
2000-05-05 0:00 ` Alfred Hilscher
0 siblings, 1 reply; 5+ messages in thread
From: Robert A Duff @ 2000-05-04 0:00 UTC (permalink / raw)
"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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-05-05 0:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-03 0:00 deallocation tasks Alfred Hilscher
2000-05-03 0:00 ` Robert A Duff
2000-05-04 0:00 ` Pascal Obry
2000-05-04 0:00 ` Robert A Duff
2000-05-05 0:00 ` Alfred Hilscher
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox