Task Access Type Variables

Task Access Type Variables

[J o s e D u a r t e]

Here's a question:

	What happens to the value of a variable which
is an access to a task (type) once the task completes
its job or terminates for some reason?

	Does this access type variable become NULL or
will it access some garbage location?

	I could just use the TVAR.all'CALLABLE or
TVAR.all'TERMINATED task attributes to see what the
status of the task that TVAR points to is. (Of
course, I'll check to make sure that TVAR /= null
before I do this).

	Does anyone know the official answer?



Just wondering,

Jose' D.

Re: Task Access Type Variables

[J o s e D u a r t e]

> Here's a question:
>
>        What happens to the value of a variable which
> is an access to a task (type) once the task completes
> its job or terminates for some reason?
>
>        Does this access type variable become NULL or
> will it access some garbage location?
>
>        I could just use the TVAR.all'CALLABLE or
> TVAR.all'TERMINATED task attributes to see what the
> status of the task that TVAR points to is. (Of
> course, I'll check to make sure that TVAR /= null
> before I do this).
>
>        Does anyone know the official answer?

Also...can garbage collection be done on task access
type variables? This seems like it shouldn't be possible.


Jose' D.

Re: Task Access Type Variables

[Norman H. Cohen]

 >         What happens to the value of a variable which
 > is an access to a task (type) once the task completes
 > its job or terminates for some reason?
 >
 >         Does this access type variable become NULL or
 > will it access some garbage location?

It continues to be a valid pointer to a task object.  The task object
just happens to designate a terminated task.  (This is no different from
what happens to a DECLARED task object when the task terminates.  The
task object continues to exist.)

 >         I could just use the TVAR.all'CALLABLE or
 > TVAR.all'TERMINATED task attributes to see what the
 > status of the task that TVAR points to is. (Of
 > course, I'll check to make sure that TVAR /= null
 > before I do this).

Indeed.  Calling an entry of a terminated task will raise TASKING_ERROR,
but one thing you CAN do with a task object designating a terminated
task is to evaluate its 'CALLABLE and 'TERMINATED attributes.  This is
why a task OBJECT must stay around even after the TASK it designates
has terminated.

(Remember:  A "task" is a process.  A "task object" is a variable
that "designates" that process and holds certain information about it,
including whether the process has terminated.)

There is no need to check that TVAR /= null.  Termination of a task
does not trigger a search for all variables holding pointers to the
corresponding task object so that those variables can be set to null!

 > Also...can garbage collection be done on task access
 > type variables? This seems like it shouldn't be possible.

I think you're asking whether dynamically allocated task objects
(rather than pointers to task objects) can be garbage collected.
The answer is yes, provided that two conditions hold:

   1. The object is no longer reachable by a chain of active pointers
      (i.e., it is "garbage" in the usual sense).

   2. The designated task has terminated.

(See paragraph 4.8(7) in the reference manual.)

Of course no Ada compiler yet provides garbage collection for ANY types,
let alone task types.

Re: Task Access Type Variables

[Jean Pierre Rosen]

In article <9107181212.aa26405@PARIS.ICS.UCI.EDU>, jduarte@liege.ICS.UCI.EDU (J
 o s e D u a r t e) writes:
> 
> Here's a question:
> 
> 	What happens to the value of a variable which
> is an access to a task (type) once the task completes
> its job or terminates for some reason?
> ...
Since the LRM says nothing special, the answer is plain: nothing special
happens!
You can use it to ask for the status of the task (T'terminated will be true)
or even call entries (which will raise TASKING_ERROR, of course).
If you UNCHECK_DEALLOCATE it, you might deallocate the task's descriptor space
(not sure any compiler does it). Don't be confused with the reverse statement:
if you deallocate a pointer to task before it is terminated, the task is
NOT affected.

This may be the place for an interesting remark about access variables in
general. A plain variable is a name that designates always the same object.
It is a kind of "constant" variable. An access variable is simply a name that
can designate different objects over time, a kind of "variable" variable.
Both behave basically the same. That's why you can write T(I), whether T is
an array or an access to an array.

An Ada access is by no mean an address!! 

Re: Task Access Type Variables

[Robert I. Eachus]

In article <9107181212.aa26405@PARIS.ICS.UCI.EDU> jduarte@liege.ICS.UCI.EDU (J 
o s e D u a r t e) writes:

	   What happens to the value of a variable which
   is an access to a task (type) once the task completes
   its job or terminates for some reason?

	   Does this access type variable become NULL or
   will it access some garbage location?

   The task object must stay around until the scope of the access type
is left, so that the attributes work and calls return the correct
exception.  (There is one special case that the ARG has decided is
pathological...  You can return a task from a function which in Ada
terms is its master.  But this pathology doesn't involve access
types.)


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