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=1.1 required=5.0 tests=BAYES_40,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!bbn!inmet!ishmael!inmet!ada-uts!stt
From: stt@ada-uts
Newsgroups: comp.lang.ada
Subject: Re: tasking question
Message-ID: <57900071@ada-uts>
Date: 12 May 88 14:44:00 GMT
References: <1133@augusta.UUCP>
Nf-ID: #R:augusta.UUCP:-113300:ada-uts:57900071:000:1372
Nf-From: ada-uts!stt    May 12 10:44:00 1988
List-Id: <comp.lang.ada>


Priority inversion is discussed in the session summary for Tasking
by Dennis Cornhill (credited to Lui Sha) in the special
issue of Ada Letters Volume VII, #6, Fall 1987 containing
the proceedings of the Internatiional Workshop on Real-Time
Ada Issues, Moretonhapstead, Devon, UK, 13-15 May 1987.

Priority inversion happens when a task is in rendezvous with
a low priority caller and a high priority task calls it.
Meanwhile, the task in rendezvous has been preempted by
a middle priority task.  The result is that a high priority
task is waiting while a middle priority task,
with which it has no synchronization, is proceeding.
A suggested solution was to define the priority of a task the
maximum of its own priority, that of its current caller,
and that of all of its pending callers (this represents a language
change).

A work-around is to make sure that an accepting task has
a specified priority at least as great of each of its potential callers,
though this may clearly create undesirable side-effects when the task
is not serving its highest-priority caller.
If the task is essentially a server or "monitor" task, with little
code outside of rendezvous, then setting it to a high priority
is probably prudent anyway so as to ensure that the shared resource
it manages is locked the minimal amount of time.

-Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138