Ada Task priorities

Ada Task priorities

[Kevin Radke]

Hello,

Can one guarantee how tasks at different priority
levels will be executed with respect to eachother?
(Speaking in both ada83 and ada95 terms...)

I.E. the following scenario:

  task a at the highest priority level
  task b at a priority level between the highest and lowest levels
  task c at the lowest priority level

Can one guarantee that if all 3 tasks are eligible for execution
at the same time, that task a will finish it's work before
task b begins to run, and task c will only run after both
tasks a and b finish? (Assuming no tasks rendezvous with
other tasks during this time?)
I suppose even OS calls would make this highly platform dependent.

The ada83 RM seems to be pretty explicit about requiring "The
highest priority eligible task must be executing at any given
time", but the ada95 RM seems less verbose about this.  Even
annex D doesn't seem to require this. (Unless I missed something
obvious, which I probably have...)

My personal opinion is that using assumptions about priorities like this
is just asking for trouble, but I thought I would get other people's opinions
on this...

Thanks!
Kevin

-- 
/\/\Under Construction/\/\ kmradke@inav.net

Re: Ada Task priorities

[Jonathan Polley]

In article <kmradke-2601971335300001@dip7.inav.net>, kmradke@inav.net
(Kevin Radke) wrote:

> Hello,
> 
> Can one guarantee how tasks at different priority
> levels will be executed with respect to eachother?
> (Speaking in both ada83 and ada95 terms...)
> 
> I.E. the following scenario:
> 
>   task a at the highest priority level
>   task b at a priority level between the highest and lowest levels
>   task c at the lowest priority level
> 
> Can one guarantee that if all 3 tasks are eligible for execution
> at the same time, that task a will finish it's work before
> task b begins to run, and task c will only run after both
> tasks a and b finish? (Assuming no tasks rendezvous with
> other tasks during this time?)
> I suppose even OS calls would make this highly platform dependent.
> 
> The ada83 RM seems to be pretty explicit about requiring "The
> highest priority eligible task must be executing at any given
> time", but the ada95 RM seems less verbose about this.  Even
> annex D doesn't seem to require this. (Unless I missed something
> obvious, which I probably have...)
> 
> My personal opinion is that using assumptions about priorities like this
> is just asking for trouble, but I thought I would get other people's opinions
> on this...
> 
> Thanks!
> Kevin
> 
> -- 
> /\/\Under Construction/\/\ kmradke@inav.net

Kevin,

     I have found that (with the Rational compiler at least) if a higher
priority task is waiting on an OS event (i.e., waiting on data from a TCP
socket), it will starve all lower priority tasks.  Because of this, I make
sure that all my I/O tasks (for TCP, UDP, and X) are the lowest priority
tasks in the system.  I have not proven, however, that tasks of the SAME
priority will NOT be starved (although they shouldn't).

Jonathan Polley
polley@netins.net
The opinions expressed here are my own, yada yada yada.

Re: Ada Task priorities

[Robert Dewar]

Kevin asked

Can one guarantee how tasks at different priority
levels will be executed with respect to eachother?
(Speaking in both ada83 and ada95 terms...)

  Yes, Annex D gives absolute rules on how priorities operate
  in Ada 95. I do not care to discuss Ada 83 rules at this stage!

Can one guarantee that if all 3 tasks are eligible for execution
at the same time, that task a will finish it's work before
task b begins to run, and task c will only run after both
tasks a and b finish? (Assuming no tasks rendezvous with
other tasks during this time?)
I suppose even OS calls would make this highly platform dependent.

  Of course not, think multiprocessors for a moment!

The ada83 RM seems to be pretty explicit about requiring "The
highest priority eligible task must be executing at any given
time", but the ada95 RM seems less verbose about this.  Even
annex D doesn't seem to require this. (Unless I missed something
obvious, which I probably have...)

  The Ada 95 requirements are FAR more explicit. Read up on the meaning
  of FIFO_Within_Priorities dispatching model.

My personal opinion is that using assumptions about priorities like this
is just asking for trouble, but I thought I would get other people's opinions
on this...

  On the contrary, there are many approaches, e.g. rate monotonic scheduling
  which absolutely rely on the invariants of priorities being observed
  accurately, and in particular on the avoidance of priority inheritance.

Re: Ada Task priorities

[Geert Bosch]

Kevin Radke (kmradke@inav.net) wrote:

   Can one guarantee that if all 3 tasks are eligible for execution
   at the same time, that task a will finish it's work before
   task b begins to run, and task c will only run after both
   tasks a and b finish? 
   
Of course not! When having a machine with more than one processor they
should run concurrently. It is perfectly legal for an implementation to
make progress in all three tasks at the same time. Using priority as
locking mechanism is very bad indeed and does not work in many cases.

   The ada83 RM seems to be pretty explicit about requiring "The
   highest priority eligible task must be executing at any given
   time", 
  
That some task is executing does not mean other tasks aren't. Even in
a single processor environment there might be smart ways of making 
progress in both tasks at once and an implementation is certainly
allowed to do that.

   My personal opinion is that using assumptions about priorities like
   this is just asking for trouble, but I thought I would get other
   people's opinions on this...

It is asking for trouble indeed. When you want to task B to wait
for task A, you should let task B wait for a rendez-vous with A.
For example in task B you say 
   accept Start do 
      null 
   end Start;
and at the end of A you call B.Start. 

Regards,
   Geert
from running you should let them make blocking calls to entries of
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943

Re: Ada Task priorities

[Geert Bosch]

Jonathan Polley (polley@netins.net) wrote:
   I have found that (with the Rational compiler at least) if a higher
   priority task is waiting on an OS event (i.e., waiting on data from a TCP
   socket), it will starve all lower priority tasks.  Because of this, I make
   sure that all my I/O tasks (for TCP, UDP, and X) are the lowest priority
   tasks in the system. 

This is really bad behaviour! You want the call for waiting on data from
a socket to be a blocking call, so it doesn't consume any CPU time at all.
Setting the I/O tasks to high priority is very desirable, because then as 
soon as an I/O task is unblocked it will get the CPU to read the port
and for example store it in a buffer for later processing. This way
response to external events is very quick, which is desirable for 
interactive use such as X Windows.

Since I/O tasks typically require the CPU only for very short periods
of time before coming blocked again, setting these tasks to high priority
shouldn't have adverse effects on the rest of the system.

The way you are implementing I/O now makes it impossible to interact
with the system while the CPU is used by calculations etc. This looks
like unwanted behavior to me.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    
      ``I think there is a world market for maybe five computers.''
        Thomas Watson,  chairman of IBM, 1943

Re: Ada Task priorities

[Michael F Brenner]

Responding to the question about making tasks A, B, and C run 
sequentially, such that B does not start until A finished, and 
C does not start until A and B finishes. 

This is not a task priority question. Task priorities determine when
a task may start with respect to other tasks starting, not with respect
to their finishing. This is a sequential requirement which must be
programmed sequentially. One way to do this is to invoke entry points
in the 3 tasks like this: 
    loop
      if a is ready then a; 
                         if b is ready then b;
                                            if c is ready then c;
                                            end if;
                         end if;
      elsif b is ready then 
                         if c is ready then c;
                         end if;
      elsif c is ready then
                         c;
      end if;
    end loop;

Of course, then there is no reason to make a, b, and c tasks at all.
Instead the above code could be the main loop of a single task.

Re: Ada Task priorities

[Robert I. Eachus]

In article <dewar.854313404@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  >> Can one guarantee that if all 3 tasks are eligible for execution
  >> at the same time, that task a will finish it's work before
  >> task b begins to run, and task c will only run after both
  >> tasks a and b finish? (Assuming no tasks rendezvous with
  >> other tasks during this time?)
  >> I suppose even OS calls would make this highly platform dependent.

  >   Of course not, think multiprocessors for a moment!

  Quite correct. There is another case to keep in mind.  If task a and
b read from disk, it is perfectly legitimate (in Ada 83 or 95) for c
to run while waiting for the I/O to complete.  This is usually a
special case of multiprocessing, but one most people overlook in
desktop systems.  (In embedded systems, I/O latencies are carefully
calculated and there is unlikely to be any disk I/O of any kind. ;-)

  In Ada it is possible to cover all the bases and get predicable
tasking behavior, but in modern systems you really have to understand
the underlying hardware design.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada Task priorities

[Kevin Radke]

In article <5cj01d$oft@top.mitre.org>, mfb@mbunix.mitre.org (Michael F
Brenner) wrote:

> Of course, then there is no reason to make a, b, and c tasks at all.
> Instead the above code could be the main loop of a single task.

In reality I simplified the question considerably.  The actual application
has 25+ tasks.  (This makes things a lot more interesting... :)

Kevin

-- 
/\/\Under Construction/\/\ kmradke@inav.net