comp.lang.ada
 help / color / mirror / Atom feed
From: Robert Dewar <robert_dewar@my-deja.com>
Subject: Re: Why does FIFO_Scheduling prefer long running tasks?
Date: 2000/05/25
Date: 2000-05-25T00:00:00+00:00	[thread overview]
Message-ID: <8gj054$13$1@nnrp1.deja.com> (raw)
In-Reply-To: slrn8iodck.tkd.lutz@belenus.iks-jena.de

In article <slrn8iodck.tkd.lutz@belenus.iks-jena.de>,
  lutz@iks-jena.de (Lutz Donnerhacke) wrote:
> I have a problem with
>   pragma Task_Dispatching_Policy(FIFO_Within_Priorities);
> which requires a preemted task to be added to the head of a
ready queue.

The problem, if any, is in your understanding
>
> IMHO this forces a running task doing a huge computation to
> block all other
> tasks with the same priority simply due to the fact, that the
computation
> does not reach syscalls (= task dispaching point) at all. So
the only
> possible task switch can be the preemtation, but this way is
forbitten.

Absolutely correct, in fact your understanding is quite correct.
This is the required and desired behavior.

> Does that mean, that the following code can stop all other
processes of the
> same priority?
>
>    loop
>       null;
>    end loop;

Of course!

> OTOH what about computionally intensive processes of higher
priority? Can
> they suspend the execution of lower priority processes for an
unbounded time?

Of course!

> I did read the corresponding part in the Rationale but did not
> get the idea.

Seems like you got the idea just fine. The only "problem" if
there is one at all, is that, presumably, for your particular
application this is not the appropriate dispatching policy
(probably your application is not a hard real time application,
but please remember we are talking about the real time annex
here).


Sent via Deja.com http://www.deja.com/
Before you buy.




  reply	other threads:[~2000-05-25  0:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-24  0:00 Why does FIFO_Scheduling prefer long running tasks? Lutz Donnerhacke
2000-05-25  0:00 ` Robert Dewar [this message]
2000-05-25  0:00   ` Lutz Donnerhacke
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox