Version 1.5 of ais/ai-00103.txt
!standard 13.11 (00) 00-01-25 AI95-00103/04
!class confirmation 95-10-12
!status Response 2000 00-01-25
!status WG9 approved 98-06-12
!status ARG Approved 12-0-0 98-04-03
!status work item 95-10-12
!status received 95-10-12
!priority Medium
!difficulty Medium
!qualifier Clarification
!subject Storage pools and access types designating task types
!summary
The specification of a user-defined storage pool for an access-to-task type
permits the user-defined allocation and deallocation of task objects,
not necessarily of the implementation-defined tasking structures that support
the task object.
!question
If a user-defined storage pool is specified for an access-to-task type,
does this imply that the user's storage pool will be used for all data
structures associated with the task, such as the TCB and the task stack?
(No.)
!response
Many implementations choose to implement a task object as an access to the
implementation-defined data structures associated with the task (such
as a Task Control Block (TCB) and a task stack). In such an implementation,
a user-defined storage pool will control only the allocation of the task
objects (i.e. the access object), and will have no effect on the allocation
and deallocation of those other resources.
Note that in some such systems, it may be impossible to allow
user-defined allocation of TCBs via the storage pool mechanism, because
the TCBs are in a separate address space, or are allocated in a run-time
system table.
!ACATS test
This permission is not testable, since it leaves what goes into a
user-defined storage-pool as implementation-defined.
!appendix
!section 13.11(00)
!subject Storage pools and access types designating task types
!reference RM95-13.11
!reference RM95-9.1
!from Offer pazy 95-10-11
!reference as: 95-5328.a Offer Pazy 95-10-11>>
!discussion
The purpose of this comment is to request the ARG to provide a
clarification of a little-known aspect of the storage pools rules. Storage
pools are allowed for access types designating task types. Nothing is
really wrong with this rule and I don't think anything is actually broken
in the standard. However, originally storage pools were requested by the
real-time community as a way to override the heap management of the vendor.
TCBs and other task storage resources were always high on the list. A
naive reader of the LRM might conclude that assigning a storage pool to an
access type designating a task task will indeed cause the user-defined
Allocate to be called for the actual TCB, or the memory block (why else
would a user write a storage pool for such a type?) which is
likely not to be the case (*). Rather, only the task object will be
allocated from the US pool. Again semantically, all is clear and simple,
but for the sake of avoiding unpleasant surprises, I would recommend
making a note to this effect.
(*) S separate issue (in my opinion) is whether or not an implementation
can actually direct allocation requests for the TCB to the UD pools without
radically rewriting its TCB management component. Some may be able too,
but many approaches make this infeasible. I don't believe that the intent
was ever to require such support.
And one final comment: I have used "dirty words" like TCBs above, knowing
that semantically they don't mean anything. However, it is clear that
anyone who deals with replacing RTS components is aware of a similar
resource.
Offer Pazy
31 Robinwood Ave.
Boston, MA 02130
USA
(617)522-5988
pazy@world.std.com
****************************************************************
Questions? Ask the ACAA Technical Agent