[PATCH 1/2] score: Replace priority prepend it with flags

[Joel Sherrill]

On Wed, Aug 11, 2021 at 2:18 AM Chris Johns <chrisj at rtems.org> wrote:
>
> On 11/8/21 3:21 pm, Sebastian Huber wrote:
> > On 10/08/2021 16:50, Sebastian Huber wrote:
> >> On 10/08/2021 16:46, Gedare Bloom wrote:
> >>> This is a good cleanup. The naming seems a bit off to me, but it's all
> >>> internal so we can always adjust it later. (I think it should be
> >>> singular "Priority_Flag", but really it's not just a flag, it's
> >>> something like the "Priority_Discipline" -- I can't think what is the
> >>> right word however for how you decide to break ties.) So you can just
> >>> leave it be for now and ignore my rambling. :)
> >>
> >> Thanks for the review. Maybe we have more flags in the future. If not we can
> >> still rename it after some time.
> >
> > Actually I am not sure if we really need more flags. What about:
>
> This is nicer.

I was just writing that discipline was the wrong word when I noticed the
extra email in the thread. Priority vs FIFO is discipline or protocol depending
on the API. This is behavior within the priority discipline.

Group behavior is an OK term.  It is about added to the priority FIFO
for your priority.

This is where this behavior is required and it has been in POSIX
for a log time since this is from 1997:

https://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutexattr_setprotocol.html

"While a thread is holding a mutex which has been initialised with the
PRIO_INHERIT or PRIO_PROTECT protocol attributes, it will not be
subject to being moved to the tail of the scheduling queue at its
priority in the event that its original priority is changed, such as
by a call to sched_setparam(). Likewise, when a thread unlocks a mutex
that has been initialised with the PRIO_INHERIT or PRIO_PROTECT
protocol attributes, it will not be subject to being moved to the tail
of the scheduling queue at its priority in the event that its original
priority is changed."

The only thing I know that depends on this behavior in the Ada run-time. But
it makes sense that if you have a priority change due to inheritance or ceiling,
then you shouldn't suffer from scheduling and getting put back at the end of
your priority FIFO.

-joel

>
> > /**
> >  * @brief The priority group flags indicate if the priority should be appended
> >  *   or prepended to its priority group.
> >  */
> > typedef enum {
> >   /**
> >    * @brief The priority group prepend flag indicates that the priority should
> >    *   be prepended to its priority group.
>
> Could this be more direct ....
>
>     * @brief The Priority group prepend option will prepended the priority
>         to the priority group.
>
> ?
>
> I am not sure `indicates` is the write word.
>
> >    */
> >   PRIORITY_GROUP_PREPEND = 0,
> >
> >   /**
> >    * @brief The priority group append flag indicates that the priority should
> >    *   be appended to its priority group.
> >    */
> >   PRIORITY_GROUP_APPEND = 1
> > } Priority_Group;
>
> I am not a fan of adding things like _FLAG because it only describes some of
> what the option is so why just have that bit when there could be so much more?
> ;) For example _FLAG could also be _FLAG_ENUM or _FLAG_DEFINE etc.
>
> Chris
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel