A few notes. All are my understanding and IMHO. - The reason that VRTX and other ancient RTOS's use 1 as the highest priority was the prevalence of "find first bit set" instructions. With e.g. 32 priorities you could in one instruction find the highest priority object that has something in it. Such single instruction optimizations have been suspect for a long time, not to mention "find last bit set" instructions. - That's why POSIX has a minimum of 32 priority levels. POSIX standards need to support a "least common denominator", and when defining the standards some either wanted to match existing practice or support suspect optimal compilation. - As for the decision to make higher priorities higher and not lower, I'd need to read the "rationale" sections of the POSIX work about priorities and POSIX. I'm guessing they were sick of saying "lower priorities are higher" and that it was time to move forward. *I* think that was a mistake, the Unix "nice" levels had the same "lower is higher" attribute as do the legacy RTOS's. - The default priority for the POSIX_Init thread should be obtained by mapping through the same function that maps classic priorities to POSIX priorities. POSIX_init is a "special" thread, and I don't see why it shouldn't have a special priority that matches the priorithy that rtems classic uses for it's init function.
It's probably safe to make the change. All existing POSIX_init applications must either elevate their priority or ensure that any spawned threads do so. > On Feb 23, 2021, at 12:47 , Joel Sherrill <j...@rtems.org> wrote: > > > > On Tue, Feb 23, 2021, 11:14 AM Heinz Junkes <jun...@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 <j...@rtems.org> wrote: > > > > > > > > On Tue, Feb 23, 2021 at 4:25 AM Heinz Junkes <jun...@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.hu...@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.hu...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
