This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems of running multiple tasks with same priority BIOSv5.41

Hi,

I have three tasks running periodically. All of them are triggered by PRD module PRD0 with period of 100ms. The PRD0 is set to be triggered by the default PRD_CLOCK. All of there three tasks have the same form as following (X as number):

All semaphores have intial value of 0, to prevent any task runs before PRD function allowed to.

void task_X(){

     while(1){

          sem_pend(semX);

           //do some calculation

           printf("debug message");

           TSK_yield();

     }

}

The PRD function simply post the semaphores:

PRD_function(){

   sem_post(sem1);

   sem_post(sem2);

   sem_post(sem3);

}

When I set these three tasks with same priority, say 13, they all ran out of control, for example, task1 would keep running and task2,3 are blocking all the time, the value of the semaphores all increased uncontrollable. And task1 was even not doing the correct computation (as I can see from the printf debug message).

However, when I reconfigure those tasks with different priority, say task1 with priority 13, task2 with 12, task3 with 11, they ran happily without errors.

Can someone suggest a solution to this problem?

Many thanks.

Best Regards,

Steven

  • The basic SYS/BIOS task scheduling rule is "The highest priority task that is ready to run, is running".

    Only when a task of higher priority than the one currently running is made ready to run will task pre-emption take place.

    Making a task ready to run that is at the same priority as the currently running task does not constitute a task pre-emption event.

    Ready tasks that share the same priority must use Task_yield() to pass the execution thread between each other.

    Alan

  • Hi Alan,

    Yes,  these tasks should be running cooperatively when they call TSK_yield(), but what would cause the problem as I describe in my first post?

    Steven

  • Steven,

    Oops. I failed to see the TSK_yield() call in your task function when I first looked at the code.

    I created a functionally identical example locally and was not able to reproduce the results you're getting. All three tasks ran as expected, and the semaphore counts never increased.

    The bad math behavior makes me wonder if the task or interrupt stacks are being overrun. Can you try increasing them?

    Alan

  • Hi Alan,

    Sorry I have hided some details, in these three tasks they perform I2C read/write to different sensors through GIO_submit() using I2C PSP driver (ver 1.30),  once they got data back, they start the computation like data scaling and then go to TSK_yield().

    Thank you for your post and I will try to debug it to see if it is the case of stack overflow as soon as possible.

    One question that bothers me after I saw your post. Why the task stacks / interrupt stacks can overflow when those three tasks are configured as the same priority? If it is the reason for stack overflow, then why it can be solved by setting these tasks as different priority?

    Best Regards,

    Steven

  • Steven,

    I'm thinking if you have a stack overflow problem it will be present in both cases. However, depending on system dynamics, the result of the overflow can be more or less fatal.

    Does the system still misbehave if you remove the printf() or replace it with LOG_printf()?

    Alan

  • Alan,

    I cannot reproduce the error by setting these tasks back into same priority now since I have develop more complexity into my code and I have increase the task stack size significantly. Beside that, I didn't change anything. So I guess it was the stack overflow which make the task running unpredictable.

    Thanks for your help!

    Cheers,

    Steven