Task reuse

Task reuse

[One Heppy Heppy 'Ket']

Fred Zwarts asked about UNCHECKED_DEALLOCATION on task access types.

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.

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?

			--- Rick Wilson

Re: Task reuse

[Robert I. Eachus]

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