pkarashchenko commented on issue #6310: URL: https://github.com/apache/incubator-nuttx/issues/6310#issuecomment-1134832614
I modified your test and added "task0.5" with priority 209 (in between of task0 and task1) and one additional semaphore (lets call it also "sem0.5"). So now task0 takes sem0.5 and g_sem at start and hold both for a fair amount of time. Them task0.5 tries to take sem0.5 and task0 prio is boosted to 209. Then your scenario is "played": 1. task2 tries to take g_sem an task0 priority is boosted to 210 2. task3 tries to take g_sem an task0 priority is boosted to 220 3. task0 post a g_sem and task0 prio is set to 210. Here with your 10.1.0+ fix `htcb->nsem_held` is still `!= 0` because of task0.5 4. then task0 runs at 210 priority while task0.5 with 209 is preempted, so neither 209 nor base prio can't be set 5. then task0 posts sem0.5 and task0 prio still remains at 209. Here your 10.1.0+ fix could help to get back to base prio, but if we add task1.5 with with prio 219 that tries to get sem0.5 or add one more mutex then we can build a cascade, so priorities will be restored to wrong values. Of course 10.1.0+ fix could help at the end when task0 does not hold any semaphore to restore to base prio, but still as I wrote this is only a fix for the corner case. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
