RTEMS POSIX Priority Inversion Issue.

Fri Dec 28 16:45:46 UTC 2018

Hi

I'm off for the holidays and answering from my phone. My suspicion is that
the pthread command is an alias for the tasks command. Thus it is not
reporting the priority from the view of the POSIX API but from the view of
the Classic API. Internally all threads and tasks are instances of
SuperCore threads and the priorities are mapped to what is required by the
API.

Priority 1 in Classic API is 254 in POSIX.

Please investigate the code for the pthread command and see if I am right.
This would be a minor bug in the shell rather than a priority inversion
issue.

--joel

On Fri, Dec 28, 2018, 1:21 AM JunBeom Kim (EmbedCoreTech) <
jbkim at e-coretech.kr wrote:

> Dear Mr. Koo.
>
>
>
> There is not any relationship between main thread and pthread1/2/3.
>
> Main thread is run on core 1 of Cortex-A9.
>
> Pthread1/2/3 threads is run on core 2 of Cortex-A9.
>
> That is, both main thread and pthread1/2/3 is run on each cores
> independently.
>
> Also, I used manual affinity using pthread_setaffinity_np().
>
>
>
> Pthread1/2/3 is created by main thread.
>
> and, actual operation is using Qt Thread API. I attached simple example
> code.
>
> Qt Thread API is calling RTEMS POSIX API.
>
>
>
> Best Regards,
>
> JunBeom
>
>
>
> *From:* chkoo at kari.re.kr <chkoo at kari.re.kr>
> *Sent:* Friday, December 28, 2018 4:05 PM
> *To:* JunBeom Kim (EmbedCoreTech) <jbkim at e-coretech.kr>
> *Cc:* users at rtems.org
> *Subject:* RE: RTEMS POSIX Priority Inversion Issue.
>
>
>
> What is the relation between main thread and pthread1/2/3?
>
> If the main thread has a control to wake up each pthread1/2/3, it gonna be
> in trouble when the prioirty of the main thread is lower than
> pthread1/2/3s because the main thread has never chance to run it, which is
> required to other threads.
>
>
>
> However why do you assign so much long integer value to priority?
>
>
>
> Cheol
>
> *--------- **원본 메일 ---------*
>
> *보낸사람* : "JunBeom Kim (EmbedCoreTech)" <jbkim at e-coretech.kr>
> *받는사람* : <users at rtems.org>
> *받은날짜* : 2018-12-28 (금) 15:45:48
> *제목* : RTEMS POSIX Priority Inversion Issue.
>
> Dear Sir,
>
>
>
> I am testing RTEMS POSIX thread priority.
>
> I am still using RTEMS 4.12 in 2017 year.
>
>
>
> There are four pthreads(main, pthread1, pthread2, pthread3) on two cores
> in my test case.
>
> - main pthread is running on core 1.
>
> - pthread1, pthread2, pthread3 is running on core 2.
>
> - All threads are doing GPIO toggling action in while(1) loop.
>
> - my configuration for timeslice quantum is 25ms.
>
>
>
> As I know from RTEMS POSIX manual, there is below statement.
>
>
>
> In the RTEMS implementation of the POSIX API, the priorities range from
> the low priority of
>
> sched_get_priority_min() to the highest priority of
> sched_get_priority_max(). Numerically
>
> higher values represent higher priorities.
>
>
>
> But, when I test this, lower value is doing as higher priority. Higher
> value is doing as lower priority.
>
> Is this correct operation ?
>
>
>
> Case 0) All threads are same priority.
>
> [/] # pthread
>
> ID       NAME             CPU SHED PRI STATE  MODES    EVENTS WAITINFO
>
> ------------------------------------------------------------------------------
>
>
> 0b010001  main_thread       1 MEDF 2147483645 READY P:T:nA   NONE
>
> 0b010002  pthread1           2 MEDF 2147483645 READY P:T:nA   NONE
>
> 0b010003  pthread2           2 MEDF 2147483645 READY P:T:nA   NONE
>
> 0b010004  pthread3           2 MEDF 2147483645 READY P:T:nA   NONE
>
>
>
> Case 1) pthread3 is lower priority according to manual. But, pthread3 is
> higher priority in my case.
>
> [/] # pthread
>
> ID       NAME             CPU SHED PRI STATE  MODES    EVENTS WAITINFO
>
> ------------------------------------------------------------------------------
>
>
> 0b010001  main_thread       1 MEDF 2147483645 READY P:T:nA   NONE
>
> 0b010002  pthread1           2 MEDF 2147483646 READY P:T:nA   NONE
>
> 0b010003  pthread2           2 MEDF 2147483646 READY P:T:nA   NONE
>
> 0b010004  pthread3           2 MEDF 1789569706 READY P:T:nA   NONE
>
>
>
> Case 2) pthread3 is higher priority according to manual. pthread1 and
> pthread2 are higher priority than pthread3.
>
> [/] # pthread
>
> ID       NAME             CPU SHED PRI STATE  MODES    EVENTS WAITINFO
>
> ------------------------------------------------------------------------------
>
>
> 0b010001  main_thread       1 MEDF 2147483645 READY P:T:nA   NONE
>
> 0b010002  pthread1           2 MEDF 1789569706 READY P:T:nA   NONE
>
> 0b010003  pthread2           2 MEDF 1789569706 READY P:T:nA   NONE
>
> 0b010004  pthread3           2 MEDF 2147483646 READY P:T:nA   NONE
>
>
>
> Please advise.
>
>
>
> Best Regards,
>
> JunBeom Kim
>
> ~~~~~~~~~~~~~~~~~~~~~~
>
> President / EmbedCoreTech
>
> Phone: +82-31-396-5584
>
> Fax: +82-504-065-5720
>
> Mobile:+82-10-6425-5720
>
> Email: jbkim at e-coretech.kr
>
> Web: www.e-coretech.kr
>
> ~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181228/c2b0081c/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 16956 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20181228/c2b0081c/attachment-0002.png>