* Purposes of Ada.Task_Identification @ 1999-06-24 0:00 Jim Rogers 1999-06-24 0:00 ` Robert I. Eachus ` (2 more replies) 0 siblings, 3 replies; 4+ messages in thread From: Jim Rogers @ 1999-06-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Purposes of Ada.Task_Identification 1999-06-24 0:00 Purposes of Ada.Task_Identification Jim Rogers @ 1999-06-24 0:00 ` Robert I. Eachus 1999-06-24 0:00 ` tmoran 1999-06-24 0:00 ` Tucker Taft 2 siblings, 0 replies; 4+ messages in thread From: Robert I. Eachus @ 1999-06-24 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Purposes of Ada.Task_Identification 1999-06-24 0:00 Purposes of Ada.Task_Identification Jim Rogers 1999-06-24 0:00 ` Robert I. Eachus @ 1999-06-24 0:00 ` tmoran 1999-06-24 0:00 ` Tucker Taft 2 siblings, 0 replies; 4+ messages in thread From: tmoran @ 1999-06-24 0:00 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Purposes of Ada.Task_Identification 1999-06-24 0:00 Purposes of Ada.Task_Identification Jim Rogers 1999-06-24 0:00 ` Robert I. Eachus 1999-06-24 0:00 ` tmoran @ 1999-06-24 0:00 ` Tucker Taft 2 siblings, 0 replies; 4+ messages in thread From: Tucker Taft @ 1999-06-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~1999-06-24 0:00 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-24 0:00 Purposes of Ada.Task_Identification Jim Rogers 1999-06-24 0:00 ` Robert I. Eachus 1999-06-24 0:00 ` tmoran 1999-06-24 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox