Priority inheritance and OS API inside protected section

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Priority inheritance and OS API inside protected section

    Hello,
    I'm writing here because i would like to have some opinion from experienced users about the "priority inheritance" of embOS tasks, it's use and it's limitations.
    In my opinion it would be a very useful feature to handle prioritized access to resources, but we found that you have to be very careful when you use some OS API.

    Here the story...

    We're using embOS for our multitasking application.

    In our application, one task have to access to a peripheral "P" in "precise" time slots, within a calculated jitter.
    This task has to run in real time, so its priority has been increased higher than the others.
    In the following days, we had to add some features to our application, including one that needs access to the same peripheral P, but in a relaxed way, by a lower priority task.
    We need mutual exclusion to access P, so I've decided to use a "resource semaphore".

    I know that embOS handles the problem of priority inversion for me, by the use of priority inheritance.
    So I was pretty confident that I would not had any problem, and the jitter would been under control.
    Infact this worked very well, until we decided to "optimize" the peripheral driver...
    We inserted an "OS_Delay(T)" inside a "busy-wait" loop, executed in the section protected by resource semaphore.
    This delay didn't change the peripheral access time, but release the CPU to other tasks.
    Surprisingly, we found that, sometime, the higher priority task was deleyed much longer than we aspect, because tasks with lower priority were running instead of it.
    Working on this, we ended with the below example. It shows that priority inheritance fails if we call the API "OS_Delay()" inside the section protected by the resource semaphore.
    If you want, run this example, and you'll see that the first "asm("NOP");" of HPTask will be executed. The resource semaphore section lasts for more than expected, showing priority inversion.
    If you comment out the "OS_Delay(10);" line in the LPTask, you'll see that the second "asm("NOP");" of HPTask will be executed, showing that "priority inheritance" works as it has to do.

    My questions are:

    - In this example priority inheritance is working the right way?
    - Are there other APIs that have the same behaviour of OS_Delay() for this example?

    Thank you :-),
    Alberto




    Brainfuck Source Code

    1. /*********************************************************************
    2. * *
    3. * OS version: 4.10 *
    4. * *
    5. **********************************************************************
    7. ----------------------------------------------------------------------
    10. --------- END-OF-HEADER --------------------------------------------*/
    13. #include "RTOS.h"
    15. OS_STACKPTR int StackHP[128], StackMP[128], StackLP[128]; /* Task stacks */
    16. OS_TASK TCBHP, TCBMP, TCBLP; /* Task-control-blocks */
    17. OS_RSEMA Resource;
    19. static void LPTask(void) {
    20. OS_DelayUntil(1000);
    21. OS_Use(&Resource);
    22. while(OS_GetTime() < 4000);
    23. OS_Delay(10);
    24. while(OS_GetTime() < 6000);
    25. OS_Unuse(&Resource);
    27. //end
    28. while (1) {
    29. OS_Delay (1000);
    30. }
    31. }
    33. static void HPTask(void) {
    34. OS_DelayUntil(2000);
    35. OS_Use(&Resource);
    36. OS_Unuse(&Resource);
    37. if (OS_GetTime() >= 10000){
    38. asm("NOP");
    39. }
    40. else{
    41. asm("NOP");
    42. }
    44. //end
    45. while (1) {
    46. OS_Delay (1000);
    47. }
    48. }
    50. static void MPTask(void) {
    51. OS_DelayUntil(3000);
    52. while(OS_GetTime() < 10000);
    54. //end
    55. while (1) {
    56. OS_Delay (1000);
    57. }
    58. }
    60. /*********************************************************************
    61. *
    62. * main
    63. *
    64. *********************************************************************/
    66. int main(void) {
    67. OS_IncDI(); /* Initially disable interrupts */
    68. OS_InitKern(); /* Initialize OS */
    69. OS_InitHW(); /* Initialize Hardware for OS */
    71. OS_CREATERSEMA(&Resource);
    73. /* You need to create at least one task before calling OS_Start() */
    74. OS_CREATETASK(&TCBHP, "HP Task", HPTask, 100, StackHP);
    75. OS_CREATETASK(&TCBMP, "MP Task", MPTask, 75, StackMP);
    76. OS_CREATETASK(&TCBLP, "LP Task", LPTask, 50, StackLP);
    77. OS_Start(); /* Start multitasking */
    78. return 0;
    79. }
    Display All

  • Hi Alberto,

    - In this example priority inheritance is working the right way?
    Yes, it is working the right way.
    The OS_Use(&Resource) in the HPTask causes the priority inheritance.
    The LPTask occupies the resource semaphore
    Instead of running further the HPTask and being blocked the scheduler runs the LPTask again.
    The basic idea is that the LPTask frees the resource sempahore with OS_Unuse().
    OS_Unuse() checks if any task is waiting for the resource semaphore which is true for the HPTask.
    Therefore the scheduler runs the HPTask again.
    But if you do a cooperative task switch with e.g. OS_Delay() before freeing the resource semaphore the LPTask is deactivated and the HPTask can't run because it is still waiting for the resource semaphore.
    In your application the MPTask runs then until it calls OS_Delay().
    In the meantimer the delay for the LPTask ended and the LPTask frees the resource semaphore which activates the HPTask.

    - Are there other APIs that have the same behaviour of OS_Delay() for this example?
    Yes, you will get the same situation with other API functions which do a cooperate task switch.


    Best regards,
    Til
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/
    Or you can contact us via e-mail.

  • Hi Til,

    Thank you very much for the reply.

    In the last days we've tried to do "by hand" what we suppose priority inheritance has to do, and we've solved our issue.

    I show here a simplified version of what we have done. I've modified the code of LPTask and HPTask the way that can seen below, and all seems to work as we want, irrespective of the cooperate task switch. The MPTask does not run anymore instead of HPTask.

    Source Code

    1. static void LPTask(void) {
    2. OS_DelayUntil(1000);
    3. OS_Use(&Resource);
    4. while(OS_GetTime() < 4000);
    5. OS_Delay(10);
    6. while(OS_GetTime() < 6000);
    8. OS_EnterRegion();
    9. OS_TASK * OwnerTask = OS_GetResourceOwner(&Resource); // this task
    10. OS_Unuse(&Resource);
    11. if(OwnerTask) OS_SetPriority(OwnerTask, 50); //I reset the priority of the LPTask to its default
    12. OS_LeaveRegion();
    14. //end
    15. while (1) {
    16. OS_Delay (1000);
    17. }
    18. }
    20. static void HPTask(void) {
    21. OS_DelayUntil(2000);
    23. OS_EnterRegion();
    24. OS_TASK * OwnerTask = OS_GetResourceOwner(&Resource); //the LPTask
    25. if(OwnerTask) OS_SetPriority(OwnerTask, 100); // I manually set the priority of LPTask to the priority of the HPtask
    26. OS_LeaveRegion();
    28. OS_Use(&Resource);
    29. OS_Unuse(&Resource);
    30. if (OS_GetTime() >= 10000){
    31. asm("NOP");
    32. }
    33. else{
    34. asm("NOP");
    35. }
    37. //end
    38. while (1) {
    39. OS_Delay (1000);
    40. }
    41. }
    Display All


    What it looks like to me, is that a cooperative switch causes LPTask to lose the priority gained during the "priority inheritance phase". Probably in the doc there is not an explicit warning, but I may be wrong, I should check ...
    I think, in big applications, it is very hard to be sure that the functions called in the semaphore protected region does not use these API, so as a rule of thumb, is better to forget that embOS does priority inheritance and protect against priority inversion in some other way ( unless we are very sure of which OS API are called by the library functions we use inside the section protected by semaphores).

    Do you agree with this? Do you suggest a better strategy?

    P.S. I didn't check the code because i'm out of office now, but it should give the idea...

    Thanks,
    Best Regards,
    Alberto