Re: How to wait for task completion

[stt@houdini.camb.inmet.com (Tucker Taft)]

wiljan (W.Derks@nl.cis.philips.com) wrote:
: Norman H. Cohen <ncohen@watson.ibm.com> wrote in article
: <51mhns$jif@watnews1.watson.ibm.com>...
: > Indeed, RM95-C.7.2(17) guarantees this.  However, unlike Ada 83, Ada 95
: > does not guarantee that unchecked deallocation will reclaim the storage
: > for a task object (or for a composite object with a subcomponent that is
: > a task object), even if the task has terminated when the deallocation
: > procedure is called!  See the last sentence of RM95-13.11.2(9).
: > 
: > I hope none of the implementors has read this sentence. :-)

: Incredible. I think here is a point to look at in the next Ada standard.

: Thanks for pointing me to the locations in the RM.

Not surprisingly, there is a bit of history behind this one.
The problem is that Ada 83 claimed that it was OK to free the task
object associated with a task that was still running, and the task
was not supposed to be affected.  We attempted to remain compatible
with this rule, while also allowing more of the critical task information 
(e.g. the Task Control Block) to be held in the task object itself.
These two rules led to task objects requiring special handling with
respect to Free.

In my view, the preferred rule would be that Program_Error is raised if 
you try to free a task object if the task is not yet terminated, but
alas that would not be upward compatible in general.

In fact, we allow Program_Error for tasks with discriminants (RM95 
13.11.3(13)), since there is no upward compatibility issue for such
tasks (Ada 83 tasks couldn't have discriminants).

The warning in 13.11.2(9) should have been replaced with a more carefully
phrased "Implementation Permission."  As it is, it comes out of the blue,
with no explanation, which is admittedly scary.

: Wiljan

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA