RE: INFO-ADA Digest V88 #47

[PETCHER%SVDSD@eg.ti.COM]

Mike Linnig asks:

> My question is... are we losing something here?   Is there
> a value to having multiple priorities even if we don't
> have preemptive scheduling?

My answer is an emphatic YES.  Granted, in a general purpose, multi-user
system multiple priorities lose a lot of meaning if a user can toss in a
program that executes forever and the OS cannot regain control.  However in
an embedded, real-time system tasks can be (and should be) designed to
cooperate.  This means, among other things, a task should not execute
indefinitely, and in fact should be designed to complete its intended
function within a predictable period of time.  This is consistent with most
actual embedded applications, where a processor has certain inputs producing
data at some predictable rate, and each task has some part in processing this
data and producing the aggregate output of the system at some required rate.

I have used prioritized, non-preemptive scheduling with reasonable success on
a couple of recent projects (not using Ada.)  The scheduling method used is
one in which the scheduler searches a table of bid flags in order of
descending task priority until it finds a flag set, whereupon it calls the
task at an entry point supplied from another, corresponding table.  When the
called task exits (returns to the scheduler) the table search is started over
from the top, thus guarranteeing the highest priority, eligible task never
waits more than one tasks execution time before getting control.  If the
table is exhausted, meaning no tasks are bid, the scheduler continues to
search it circularly until one is (in this case, necessarily, due to an
interrupt.)  To maintain performance goals and assure higher priority tasks
are executed relatively soon, functions requiring excessive time are either
broken up into multiple tasks, each completing its part of a process then
bidding the next in the sequence, or are implemented as a single task with
multiple checkpoints.

The advantages to this method are time efficiency, since no context saving
and restoring are required, ease of implementing the scheduler code itself,
consisting of some half dozen lines of executable code in C, and the
corresponding space efficiency.  The main disadvantage lies in the need for
all software designers on a project to be cognizant of task execution time
constraints and stay within them.

Malcolm Petcher
Texas Instruments, Inc.