Purposes of Ada.Task_Identification

Purposes of Ada.Task_Identification

[Jim Rogers]

 I occasionally wonder what the intended purpose of the package
Ada.Task_Identification is. You cannot use the Task_ID to call
a task entry.

You can determine whether or not two task access objects access the
same task. You can determine whether or not a task is terminated
or callable. Finally, you can abort a task via the Task_ID.

Of course, you can determine whether or not a task is callable or
terminated without using Ada.Task_Identification. You can also
abort a task without using Ada.Task_Identification.

Is the only real use of this package to determine if two different
ID objects refer to the same task? Is this a common need? I have
never used a system that needs this ability.

--
Jim Rogers
Colorado Springs, Colorado USA


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Purposes of Ada.Task_Identification

[Robert I. Eachus]

Jim Rogers wrote:
> 
>  I occasionally wonder what the intended purpose of the package
> Ada.Task_Identification is. You cannot use the Task_ID to call
> a task entry.
> 
> You can determine whether or not two task access objects access the
> same task. You can determine whether or not a task is terminated
> or callable. Finally, you can abort a task via the Task_ID.
> 
> Of course, you can determine whether or not a task is callable or
> terminated without using Ada.Task_Identification. You can also
> abort a task without using Ada.Task_Identification.
> 
> Is the only real use of this package to determine if two different
> ID objects refer to the same task? Is this a common need? I have
> never used a system that needs this ability.

    No.  There are several uses for Ada.Task_Identification, however,
determining whether two tasks are the same task is not a justification
for it.

    First, in Ada 83, you could only abort a task if you statically knew
its type.  (This does not mean that the task to be aborted had to be
statically determined, but that the type of the task had to be.)  Using
Ada.Task_Identification, you can do things like having arrays of
Task_IDs, and manage heterogenous tasks from a single manager.

    Second, look at the package Ada.Task_Attributes.  This package is
very useful for inheriting values from the parent task, and then being
able to update a local copy without requiring a synchronization with the
parent.  Think Environment Variables in Unix.  The definition of this
package requires a way to refer to a task independent of its type.  So
Ada.Task_Identification is necessary to support this feature.  (This is
the primary reason it is in Ada 95.)

    Oh, one other "neat" feature of Ada.Task_Attributes.  A task can
define task specific data that can be referenced by the called task
during a rendezvous. (You want the data from the called task of
course.)  One of the most important uses of this is for data that can be
maintained without task synchronization.  In other words, setting the
data requires a rendezvous, but it can be read without synchronization. 
Hmmm. That's still not very clear.  Let's say you have comm ports that
can be assigned to tasks.  As long as that task owns the comm port,
communication through the (hardware) port doesn't require any software
level synchronization.  The routines for seizing and releasing the ports
is encapsulated in a protected object, but normal operations don't
require any synchronization.  (Of course, you could make the port id a
parameter in all the calls, but why tempt fate and dumb programming
errors?)

    Third, Task_IDs can be used to dynamically change task priorities
(see D.5).  Very useful if you are building your own scheduler, or more
likely want to elevate the priority of the task while it holds some
critical resource.  (Of course, you want to save the normal priority
value and deal with all the issues of locking order. 
Ada.Task_Attributes is great for this.  Just assign a number to each
lock and refuse to let a task acquire a lower numbered lock than one it
is holding.  When you release a lock, if it is the highest numbered lock
held, then revert to the priority when the next lower lock was
acquired.) 

   And last, there is one cute idiom that involves
Ada.Task_Identification.  The main program runs inside an "environment
task."  Aborting the environment task aborts the main program, all of
its tasks, and all tasks created by library level packages.
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Purposes of Ada.Task_Identification

[tmoran]

> I occasionally wonder what the intended purpose of the package
>Ada.Task_Identification is.
  It's sometimes handy for a resource locking routine to know if
the currect request in fact comes from the current owner of the
resource.  A comparison of the Id of the owner to that of the
requestor will answer that question.
  Some compilers will return True for Is_Callable(the environment task)
while the main program is running, and False after it has terminated
(and is waiting for child tasks to terminate).  I understand there's
an AI in the works to make this standard practice.  Where it works,
it allows a long-running task to detect that the program is trying
to stop, and to stop itself.  This handles situations where a
"select ... or terminate", or an abort, are inappropriate.
  Sometimes in debugging a multi-tasking system it's nice to be
able to log some activity and include in the log which task performed
that activity.
  That's just how I use Ada.Task_Identification.

Re: Purposes of Ada.Task_Identification

[Tucker Taft]

Jim Rogers wrote:
> 
>  I occasionally wonder what the intended purpose of the package
> Ada.Task_Identification is. ...

> Is the only real use of this package to determine if two different
> ID objects refer to the same task?

Task IDs are used in a number of other packages.  For example,
the Dynamic_Priorities package relies on task IDs for setting
and getting the priority of another task.  As others have pointed
out, task IDs are also useful for managing a heterogenous
collection of tasks by stuffing their task IDs into an array.

> --
> Jim Rogers
> Colorado Springs, Colorado USA

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA