!standard 13.11    (00)                               98-04-01  AI95-00103/01
!class confirmation 95-10-12
!status work item 95-10-12
!status received 95-10-12
!priority Medium
!difficulty Medium
!subject Storage pools and access types designating task types

!summary 98-04-01

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 the implementation-defined tasking structures that support the
task object. 

!question 95-10-12

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 TCB's and task stacks?
(No.)

!response 98-04-01

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.

!appendix 95-10-12

!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

****************************************************************