From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!pt.cs.cmu.edu!sei!Goodenough
From: Goodenough@sei.cmu.edu
Newsgroups: comp.lang.ada
Subject: Non-static priorities
Message-ID: <8485@aw.sei.cmu.edu>
Date: 8 Feb 89 18:04:21 GMT
Sender: jbg@sei.cmu.edu
List-Id: <comp.lang.ada>


In the past few weeks, I've heard a number of complaints concerning the
requirement for static expressions in pragma PRIORITY.  These complaints
reflect two needs:

	1.  The ability to set a task's priority within a generic unit, i.e.,
	    it would be nice if different instances could have different
	    priorities, and

	2.  It would be nice to specify that a software task runs at a
	    hardware priority level.

It seems to me (i.e, non-official opinion), that implementations are allowed,
but not required, to meet both requirements and still conform to the standard.
For example, suppose a hardware priority level is equivalent to PRIORITY'LAST
+ 5.  (Usually PRIORITY'LAST is much less than INTEGER'LAST.)  So we write a
task specification:

	task T is
	    pragma PRIORITY (PRIORITY'LAST + 5);
	    entry ...
	end T;

Since PRIORITY'LAST + 5 exceeds the range of priorities, the pragma has no
effect, i.e., task T has no defined priority in the Ada sense.  This means the
implementation is free to schedule it as though it had any priority
the implementation chooses to give it.  In particular, the task could be
scheduled _as_ _though_ it had PRIORITY'LAST + 5!  For example, it could
preempt the execution of a task that has PRIORITY'LAST, since 9.8(6) says
nothing about how tasks with no priority are scheduled.  Of course, 13.5.1(2)
says:

	An interrupt acts as an entry call issued by a hardware task whose
	priority is higher than the priority of the main program, and also
	higher than the priority of any user-defined task.  

This paragraph doesn't contradict my argument.  The term "priority" has a
technical meaning in the standard.  This meaning is given by 9.8 and refers to
the priority specified by pragma PRIORITY for a given task.  Since task T
above has no defined priority in the Ada sense, it can execute at a priority
that preempts interrupts if an implementation so chooses.  9.8 doesn't specify
what execution preference is to be given to tasks with no defined priority.

The same approach works for a pragma PRIORITY given within a generic unit:

	generic
	    PRI : INTEGER;
	package TASKS is
	    task T is
		pragma PRIORITY (PRI);
	        ...
	    end T;
	end TASKS;

	package MY_TASK is new TASKS (N);

MY_TASK.T has no defined priority, so an implementation is free to schedule it
as though it had a priority that is the value of N when the instantiation is
elaborated.

Robert Dewar has pointed out to me that this interpretation even works for
rendezvous priorities.  If MY_TASK.T calls a task with a defined priority, the
rendezvous is executed with "at least" the called task's priority; hence, it
could be executed with MY_TASK.T's effective priority if this is considered to
be higher than the called task's priority.

In short, it seems to me that implementations are allowed to support
non-static and interrupt level priorities if they wish to do so.

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391