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