!topic LSN on Task Storage Size
!key LSN-1075 on Task Storage Size
!reference RM9X-13.3(28-30);4.0
!from Offer Pazy $Date: 94/01/28 17:04:03 $ $Revision: 1.5 $
!discussion

Several comments were sent to the MRT complaining about the difficulty of
implementing the Storage_Size clause for stand-alone task objects. This
is due to the fact that the value of this clause may be dynamic and
available to the implementation only after the task itself has been created.
In general, it is either impossible or very difficult to change or extend
the task's stack after the task has been created.

However, the capability to tune the storage size (e.g. stack size) of
individual task objects is considered important and is consistent with the
general approach of 9X which provides object-level control of task parameters
(vs the type level control provided by Ada 83).

It was suggested that a pragma should be provided to specify the task
storage size.  The purpose of this LSN is to describe the semantics of this
new pragma, and its interactions with the 'Storage_Size attribute.

The Semantics of the New Pragma:

The Pragma

    Storage_Size (integer_expression)

is allowed only within a task_definition. The expression of the pragma is
per-object, meaning that it is evaluated for each new task object when it
is created. Thus, if the expression depends on a discriminant, a
straight-forward parameterization of the task storage size may be programmed.
If the expression is static, then naturally, the same size will be used for
all task objects of the type (but the expression is still considered
per-object).  We do not propose a separate mechanism for setting the storage
size for an entire type (the same effect may be achieved by simply coding an
expression that always yields the same value), because it is not clear that
the added complexity provides a real user benefit.  The complexity comes from
the need to decide which specification takes precedence when different values
are specified for the type and objects of the type.

[Shall we call this pragma Storage_Size like the attribute ? Or
Task_Storage_Size, a) to emphasize that we only have it for tasks, and b)
to avoid potential conflicts with implementation-defined pragmas named
Storage_Size ?]

The reason that the pragma mechanism is easier to implement is because the
storage size specification now appears *within* the task_definition, instead of
outside it.  This means, that this information is always available to the
compiler when it creates task objects; unlike the situation before when the
storage size specification could appear much later and be dynamic.  We could
of course, move the Storage_Size clause inside the task_definition, but
this would be quite inconsistent with the general placement of
attribute_definition_clauses. On the other hand, the proposed new pragma
is quite consistent with the Priority pragma (in placement, evaluation
rules, and usage).

The value of the expression instructs the implementation to allocate at
least that much storage for the task object.  Implementations may add to
this value (if rounding, or a head-room is required).  The intention is
that the task stack size will be included in the value of the pragma. But
weather or not other resources (such as the TCB) are included will be
implementation-defined.

Interactions With the 'Storage_Size Attribute:

The 83 rules (i.e. the storage size is both settable and query-able for a
task type) are equivalent to what we call now type-related. We propose to
make this feature obsolescent. Otherwise, we will have to define all the
interactions between the pragma and the attribute cases.  Also, with the
proposed meaning of the pragma (per-object), it is not clear what a query
on the type would mean.  The interactions are therefore left to be defined
by the implementation.

The Storage_Size attribute (as a query) will still be allowed for task
objects, with the same semantics.  Only the query on types will become
obsolescent. The attribute will return the value set by the pragma, after
any implementation-defined rounding up (adding headroom, etc.) (This is
not a change from v4.0).