• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 21 subscribers
  • Views 2460 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Change thread priority

Elham Kashefi

Hi friends,

I have three threads in my RTOS. When I define priorities for all threads identically, there is no problem and all the three threads run normally. But when I change the priority of one of threads (to above the priority of other two) the other two threads do not execute. Is there any property that I must change or define to be able to change the priority? Or sth. else?

My threads' definitions in normal case:
osThreadDef (job1, osPriorityAboveNormal, 1, 0);
osThreadDef (job2, osPriorityAboveNormal, 1, 0);
osThreadDef (job3, osPriorityAboveNormal, 1, 0);

My threads' definitions when have problem:
osThreadDef (job1, osPriorityAboveNormal, 1, 0);
osThreadDef (job2, osPriorityAboveNormal, 1, 0);
osThreadDef (job3, osPriorityHigh, 1, 0);

p.s.: I have tried other priorities like osPriorityAboveNormal and ..., but the problem persists.

Your prompt response would be greatly appreciated,
Elham

  • 0

    In an RTOS, a lower priority thread must be preempted if a higher priority thread is ready to run. Your highest priority thread seems to always be available to run (it is not "waiting" for some event to happen) so it is the one running. There behavior is expected and required by an RTOS.

    threads running in an RTOS are often "doing nothing" except waiting for an even to happen. When the event happens, the thread is put into the READY queue and will be given the processor based on thread priority (Highest priority thread that is ready to run will be given the CPU)

  • 0 in reply to Robert McNamara

    Thanks Robert for getting me back quickly,

    I understand what was wrong, however, how can I solve it?

    Regarding the example in below address:
    www.keil.com/.../group__CMSIS__RTOS__SemaphoreMgmt.html

    I am wondering what exactly happens when timeout parameter expires in osSemaphoreWait function? I guess it would switch the state of the waiting thread from "waiting" to "ready". But what about the taken semaphore? The semaphore has been taken by the lower priority thread and the higher priority thread is in ready state now, but cannot acquire semaphore. So, in my opinion, starvation happens.

    I have tried this among my three threads:
    osThreadDef (job1, osPriorityNormal, 1, 0);
    osThreadDef (job2, osPriorityAboveNormal, 1, 0);
    osThreadDef (job3, osPriorityHigh, 1, 0);

    When I use empty while(1) for three threads, everything seems ok. But when I add my actual code, none of them executes. I guess the lowest priority thread does not free the semaphore and because its while(1) bodylen is long (much more than the thread's time slice), starvation occurs.