Re: Purposes of Ada.Task_Identification

["Robert I. Eachus" <eachus@mitre.org>]

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