!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 ****************************************************************