From: eachus@aries.mitre.org (Robert I. Eachus)
Subject: Re: Task reuse
Date: 1 Mar 90 20:16:22 GMT [thread overview]
Message-ID: <EACHUS.90Mar1151622@aries.aries.mitre.org> (raw)
In-Reply-To: WILSON@amstel.llnl.gov's message of 1 Mar 90 01:54:00 GMT
In article <9003010229.AA02234@ajpo.sei.cmu.edu> WILSON@amstel.llnl.gov (One Heppy Heppy 'Ket') writes:
> Mats Weber and Norman Cohen correctly responded that there is
> not necessarily any effect. Norman suggested that "good" compilers
> will reclaim the storage occupied by a terminated task. I don't
> know how good this really is, since I can't rely on it from one
> compiler to the next, or ever from one version of a compiler to the
> next! In fact, a compiler which supports this can mask program bugs
> which might turn up at porting time.
> I think that with the current Ada spec, Mats has the only right
> answer, which is to maintain a task pool, and "manually" keep track
> of which tasks have completed their basic function, in order to
> reuse them.
In general the Ada paradigm is to create a small number of task
objects and keep reusing them. The impact of this on compiler
writers is that they make rendezvous fast even though this slows down
task elaboration. Ada tasks designated by access values in general
must remain around "forever", and since in most implementations the
task objects are on the order of two dozen bytes in size, this is not
a severe penalty. (An Ada implementation which puts the task stack in
the task object is just wrong...)
If you must create tasks in an Ada program in a way that ALL
associated storage is reclaimed, do not designate them by access
types. Again this is an Ada design decision that should be
recognized by programming style. "Normal" Ada tasks can be put on
the stack, tasks designated by access values are weird animals that
may outlive not only the guy who created them, but also the main
program. A compiler which follows these things around with a broom
is wasting its time.
> This seems to be a pretty general need in the Ada environment.
> I am wondering if anyone has written any generic packages which
> support this task pool concept? I've designed a few, but they've
> always come out too tightly coupled to the task body's rendezvous
> algorithm. Has anyone else solved this problem in general terms, or
> worse, proven that it can't be solved?
I don't know what you mean here. It is easy to write a package
which exports a message type and to have the implementation of the
message use a task. The right way to write the body is to keep a
list of such tasks that are free and only create a new one when the
list is empty. When I do this I use a generic package with a
subprogram parameter which is the entry point to call (unfortunately
you can't pass an entry as an entry. The other model is to pass the
name of the target task to the send procedure...
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
prev parent reply other threads:[~1990-03-01 20:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1990-03-01 1:54 Task reuse One Heppy Heppy 'Ket'
1990-03-01 20:16 ` Robert I. Eachus [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox