Annotated Ada Reference Manual (Ada 202y Draft 1)Legal Information
Contents   Index   References   Search   Previous   Next 

D.4.1 Admission Policies

1/5
{AI12-0276-1} [This subclause specifies a mechanism for a user to choose an admission policy. It also defines one such policy. Other policies are implementation defined.]
1.a.1/5
Implementation defined: Implementation-defined admission policies.

Syntax

2/5
{AI12-0276-1} The form of a pragma Admission_Policy is as follows:
3/5
  pragma Admission_Policy (policy_identifier);

Legality Rules

4/5
{AI12-0276-1} The policy_identifier shall be either FIFO_Spinning or an implementation-defined identifier.

Post-Compilation Rules

5/5
{AI12-0276-1} An Admission_Policy pragma is a configuration pragma.

Dynamic Semantics

6/5
{AI12-0276-1} An admission policy governs the order in which competing tasks are evaluated for acquiring the execution resource associated with a protected object. The admission policy is specified by an Admission_Policy pragma.
7/5
{AI12-0276-1} One admission policy, FIFO_Spinning, is language defined. If FIFO_Spinning is in effect, and starting a protected action on a protected object involves busy-waiting, then calls are selected for acquiring the execution resource of the protected object in the order in which the busy-wait was initiated; otherwise the FIFO_Spinning policy has no effect. If no Admission_Policy pragma applies to any of the program units in the partition, the admission policy for that partition is implementation defined.
7.a/5
Discussion: {AI12-0005-1} Busy-waiting might be used for protected objects that can be called from tasks running on other processors than the one the protected object is on. It is unnecessary if all of the tasks that can call a protected object are on the same processor as the object; in particular, it would not be used on a monoprocessor. Aspect CPU (see D.16) can be used to ensure that busy-waiting is not needed. 
7.b/5
Implementation Note: A possible implementation for this policy would be to apply the abstraction of a ticketing system by assigning two sequence number values to each protected object. One sequence number represents the next available ticket number, and the other sequence number represents the ticket number currently being serviced by the protected object. The next available ticket number is incremented and assigned to a task when the task initiates a busy-wait for acquiring the execution resource associated with the protected object. The ticket number currently being serviced is incremented when a task releases this execution resource. As part of acquiring the execution resource, a task busy-waits until its assigned ticket number equals the protected object's value for the ticket number currently being serviced. While a task busy-waits, it monitors the active priority of the protected object in order to inherit any modifications to the protected object's active priority. 

Implementation Permissions

8/5
{AI12-0276-1} {AI12-0444-1} Implementations are allowed to define other admission policies, but are not required to support specifying more than one admission policy per partition.
8.a/5
Discussion: This rule is in fact redundant, as 10.1.5 allows an implementation to limit the use of configuration pragmas to an empty environment. In that case, there would be no way to have multiple policies in a partition. 

Extensions to Ada 2012

8.b/5
{AI12-0276-1} Admission Policies and the specific policy FIFO_Spinning are new. 

Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe