On Wed, Aug 11, 2021 at 2:18 AM Chris Johns <chr...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
