How do we know what priority of the Init task is?

[Joel Sherrill]

On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes <junkes at fhi-berlin.mpg.de>
wrote:

> Thank you for the detailed explanation. I may have asked my question
> incorrectly.
>
> If I choose POSIX_Init for RTEMS the Init process has a very low priority
> and if I use
> the normal (RTEMS) Init a very high priority. This does not fit in my
> opinion.
>
> Shouldn't the POSIX_Init - process have the prio 98 or so?
>

No. To match, it would need to be 254 but it gets the default pthread
attributes which are implementation defined.  Being very low is probably a
good punishment for not specifying what you wanted in an application but
may not have been the best choice for POSIX init thread.

The ability to set very few attributes on the posix initialization thread
was a deliberate decision because you have to set them via API calls and
that would have increased the minimum footprint of a posix application to
include all pthread attribute set methods.

I don't have a good solution in mind. :(


> Heinz
>
> > On 23. Feb 2021, at 15:17, Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes <junkes at fhi-berlin.mpg.de>
> wrote:
> > what I have just never understood
> >
> > POSIX  Prio 2 ist LOW Priority
> > RTEMS Prio 1 is HIGH Priority
> >
> > In general, RTOS threading APIs tended to use 1 as a high priority. The
> RTEMS
> > Classic API based on pSOS+, VxWorks, and VRTX32 which preceded all those
> > all follow 1 is high priority model.
> >
> > POSIX calls for the opposite range. Not sure why. Interestingly, I had a
> discussion
> > with the main kernel person for another RTOS about this in a standards
> meeting
> > and he noted that although every implementation of POSIX threads we both
> knew
> > about does use low number as low priority, it is not as explicit in the
> POSIX standard
> > as one would think. We have just all read the same text that way since
> POSIX is
> > careful to say raises or lowers priority and the implication we all saw
> is that the
> > numbers follow that languge. But at this point, the priorities run this
> way for no
> > other reason than history and compatibility. For all I know, it may even
> be baked
> > into the POSIX Compliance Test Suite. Any program with hard-coded numbers
> > certainly has it baked in.
> >
> > While I am beating this topic mercilessly, let me point out that POSIX
> only calls
> > for a minimum of 32 priority levels. Portable programs cannot assume
> more.
> > And the default attribute set for all POSIX threading and
> synchronization
> > objects is implementation defined. Portable programs should always
> explicitly
> > set all attributes for pthreads, mutexes, etc.
> >
> > The RTOS choice probably reflects using a bitmap to represent if a thread
> > is present on the FIFO for each priority. This would make a bit index map
> > directly to priority in most cases. This design dates back to at least
> VMS
> > where you have 32 priority levels because you could scan 32 bits in a
> > single instruction. This was carried forward into Windows NT.
> >
> > THe diversity of choices reminded me of this quote from Andrew Tanenbaum:
> >
> > "The nice thing about standards is that there are so many of them to
> choose from."
> >
> > In the end different people had an arbitrary decision and picked
> different
> > answers. Ada task priority is another set of choices. :)
> >
> > --joel
> >
> >
> > Heinz
> >
> >
> > > On 23. Feb 2021, at 09:17, Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> > >
> > > On 23/02/2021 08:36, Heinz Junkes wrote:
> > >
> > >> I would have a similar question ;-)
> > >>
> > >> What is the priority of the POSIX_Init - Task (as Posix-Prio)?
> > > There is no option to configure the priority of the POSIX
> initialization thread, so the default priority of 2 is used, see
> _POSIX_Threads_Default_attributes.
> > >
> > > --
> > > embedded brains GmbH
> > > Herr Sebastian HUBER
> > > Dornierstr. 4
> > > 82178 Puchheim
> > > Germany
> > > email: sebastian.huber at embedded-brains.de
> > > phone: +49-89-18 94 741 - 16
> > > fax:   +49-89-18 94 741 - 08
> > >
> > > Registergericht: Amtsgericht München
> > > Registernummer: HRB 157899
> > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > > Unsere Datenschutzerklärung finden Sie hier:
> > > https://embedded-brains.de/datenschutzerklaerung/
> > >
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210223/0ef44182/attachment.html>