Why does FIFO_Scheduling prefer long running tasks?

Why does FIFO_Scheduling prefer long running tasks?

[Lutz Donnerhacke]

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.

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.

Does that mean, that the following code can stop all other processes of the
same priority?

   loop
      null;
   end loop;

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

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

Re: Why does FIFO_Scheduling prefer long running tasks?

[Lutz Donnerhacke]

* Robert Dewar wrote:
>> I did read the corresponding part in the Rationale but did not
>> get the idea.
>
>Seems like you got the idea just fine.

Thanks.

>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).

Of course. I was thinking of preparing my experimental OS for this annex.
So now I know, that I need an other scheduling algorithm for normal work.

Thanks a lot.

Re: Why does FIFO_Scheduling prefer long running tasks?

[Robert Dewar]

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.