Re: Priority Ceiling

["Robert I. Eachus" <rieachus@attbi.com>]

Stephan Heinemann wrote:

> Now the questions:
> (1)
> If I understood correctly then the task priority should be raised to the
> ceiling priority of the protected object (immediate ceiling priority
> protocol). However, I cannot obtain this new active priority using
> "Get_Priority(Current_Task)"; the base priority is returned instead. Why?

Because that is the way Get_Priority is defined:  D.5(8):

"The function Get_Priority returns T's current base priority."

If you think about it any other definition would be unfriendly.

> (2)
> The procedure "Priorities" would run with default priority (15) if
> pragma Priority(0) was not given. But this change seems to affect the
> defined tasks as well, eventhough they have their own base priorities
> assigned to them. Do they inherit their priorities from the
> "Priorities"-executing task, if they are assigned lower base priorities
> than the latter?

That is actually about a dozen questions...

First, the procedure "Priorities" will only run with a priority other 
than the default if it is the main program, the main program contains a 
pragma Priority, or Priorities is called by a task with a non-default 
priorty.

To turn that around in a way that makes sense, a pragma Priority in the 
main program can set the priority of the environment task.  At any other 
point, the priority of a subprogram is the (current) priority of the 
task it is executing in.

Next D.1(21): "During activation, a task being activated inherits the 
active priority that its activator (see 9.2) had at the time the 
activation was initiated."

In other words, during task creation the task runs with the priority of 
its creator.  This allows a high-priority task to create a 
lower-priority task without having to wait for that process to complete. 
  After that a task will run with its own priority, except when it 
inherits a higher priority during a rendezvous, or runs at the priority 
ceiling of a protected object, or when its priority is changed (or set) 
by a call to Ada.Dynamic_Priorities.Set_Priority.

Note that with pragma Locking_Policy(Ceiling_Locking) the ceiling 
priority of a protected object is, by default, Priority'Last, but it can 
be set as high as Interrupt_Priority'Last.  (And is not less than 
Interrupt_Priority'First if a pragma Interrupt_Handler or Attach_Handler 
  appears in the protected object.)

A task that attempts to call an entry, procedure, or function of a 
protected object whose ceiling is less than the current priority of the 
task, Program_Error will be raised.

So if you try to play with this stuff without design tool support it 
gets hard fast.  The tools can tell you the base priority of each task, 
the highest priority it will inherit, and any case where it might 
violate a priority ceiling.  Of course, you can use Set_Priority with 
run time computed values to confuse the best of priority inheritance 
design tools.  Of course, tasking design tools is not my area of 
experitise, so maybe some other posters will recommend some.

-- 

                                                        Robert I. Eachus

�In an ally, considerations of house, clan, planet, race are 
insignificant beside two prime questions, which are: 1. Can he shoot? 2. 
Will he aim at your enemy?� -- from the Laiden novels by Sharon Lee and 
Steve Miller.