Naming of Fixed-Priority Scheduler (Now is Rate-Monotonic Scheduler)

[Gedare Bloom]

On Thu, Sep 22, 2016 at 10:06 AM, Kuan Hsun Chen
<kuan-hsun.chen at tu-dortmund.de> wrote:
> Hello all,
>
> One question about the naming of rate-monotonic scheduler.
> I believe is not the serious problem in the past most likely.
> However, when RTEMS becomes more powerful and popular, I guess this question
> will emerge.
>
> We all know that Rate-monotonic (RM) is a well-known optimal scheduling
> under fixed-priority assignment when the task model is based on implicit
> deadline (I guess in the past most of real-time applications using RTEMS
> follow this design rationale).
> When we further consider constrained-deadline task model, Deadline-monotonic
> (DM) is the optimal rather than RM. In fact the users can decide the
> priorites of tasks themselves, and our kernel does not provide any standard
> scheduling to automatically help the user sort/assign the priorities of
> tasks even RM that using the periods of tasks to determine the priorities.
>
> This rate_monotonic "prefix" so far takes place everywhere in the manual,
> source code, or user applications. However, since RTEMS does not really
> provide the service about the automatic priority assignment yet, this will
> confuse the following users when they start to implement their applications
> or follow the manual. In my opinion, we should rename this prefix to
> fixed-priority or something else neutral.
>
Thanks for the detailed description. We can't really change these
functions since they are part of the Classic API that we keep (mostly)
backwards-compatible. It can be a possibility to introduce a new API
that supersedes the RM, and then RM becomes a wrapper for that API.

> Furthermore, we can really integrate some well-known priority assignments
> and scheduling policy into the kernel to provide automatic priority
> assignment but also keep the flexibility of scheduler (like add one more
> parameter to enable/disable the flexibility). This kind of design can be
> found in LitmusRT as well.
>
Yes, this could be done by introducing a new API for periodic tasks.
But the priority assignment algorithms take into consideration all of
the possible tasks in the system, which is not known at runtime in
current RTEMS APIs. For example, if you use DM scheduling, there must
be a way to determine how to map deadlines to priorities, which is not
easily doable unless all the tasks' deadlines are known or the
previously assigned priorities can be changed due to creation/start of
a new task whose deadline does not fit in the available remaining
priorities.

Gedare

> I know it must be a long-term perspective, but I believe it is good to
> achieve it for future usage.
>
> Cheers,
> Kuan-Hsun
>
> --
> M.Sc. Kuan-Hsun Chen
>
> TU Dortmund
> Department of Computer Science 12
> Design Automation of Embedded Systems
> Otto-Hahn-Strasse 16, Room 102
>
> 44227 Dortmund
> Germany
>
> Phone:  +49 231 755 6124
> Mail:   kuan-hsun.chen at tu-dortmund.de
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users