WILSON@amstel.llnl.gov (One Heppy Heppy 'Ket') (03/01/90)
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
eachus@aries.mitre.org (Robert I. Eachus) (03/02/90)
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...