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

Tue Feb 23 22:26:08 UTC 2021

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 <dufault at 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 <joel at rtems.org> wrote:
>> 
>> 
>> 
>> 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
>> 
>> _______________________________________________
>> devel mailing list
>> devel at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210223/33acf8bb/attachment.bin>