I re-read Joel's mail and I agree, the priority should be left ridiculously low (as it is now) or maybe set in the middle (but why bother?).
I was thinking about matching classic RTEMS behavior. I don't think it matters in POSIX. > On Feb 23, 2021, at 17:12 , Peter Dufault <dufa...@hda.com> wrote: > > Signed PGP part > 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. > > > 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
