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.
Hi
I am trying to use the osThreadYield function of the CMSIS-RTOS and even though I have many other threads in the READY state, control is not passed to them and I stay in the current thread which basically hangs the entire system.
This thread is the highest priority thread which is polling a CAN bus interface for messages but I want it to give up control to allow other tasks if they need to run.
I suspect that there is a statement missing from the description below that as task will give up control to HIGHER prioirty threads that are READY. Not just any thread as they imply below.
Does anyone know if this is the case? Or why this highest priority thread will not give up control when asked to?
Thanks Steve
osStatus osThreadYield ( void )
Returns status code that indicates the execution status of the function.
Note MUST REMAIN UNCHANGED: osThreadYield shall be consistent in every CMSIS-RTOS.
Pass control to the next thread that is in state READY. If there is no other thread in the state READY, the current thread continues execution and no thread switching occurs.
Note that yield will not drop the thread priority.
So the OS will only look for other threads of same priority that is ready. Yield is intended for round-robin execution of multiple same-priority threads.
A high-priority thread that have nothing to do should sleep - either a fixed amount of time, or waiting for some event, mail or similar. Then it will be able to take advantage of that higher priority to get first in line when it finally gets something to do.
Thanks for getting back to me quickly.
I wish they put that one sentence in the online definition for the command. This is a really important point they totally left out.
This is what I thought but there is not documenation to confirm this. I will need to reorder my priorities so that osYieldThread will allow the other tasks that I want to have some processing time will be able to run.
thanksa again.
In my conclusion,
1, when OS tick(like 1ms) expires, if there's no higher priority thread ready, the current thread continues to execute.
2, when osThreadYield is called, if there's no same or higher priority thread ready, the current thread continues to execute.
3, if using round-robin, when the time specified(like 5ms) expires, if there's no same or higher priority thread ready, the current thread continues to execute.
When a thread with a higher priority becomes READY it will start to execute. There is no need to call osThreadYield for that. This is documented here: www.keil.com/.../group___c_m_s_i_s___r_t_o_s___thread_mgmt.html
Thanks also for pointing out the weakness in the documentation. We will add more information to the function description of osThreadYield.
The problem with documenting the API of an OS, is that the documentation has to assume that the user knows a number of general OS concept. Yield is a common OS concept and the Keil version of Yield behaves as expected from a Yield.
I do not necessarily agree.
Yield means to to "give up" and without any other qualifiers it needs to be explained in the documentation as to what will gain control.
The concept of Yield in other embedded OS's I've worked with do not have a only yield to greater thread concept in a round robin where all threads have a chance to run.
Yes, but Yield within the "OS concept space" means "give up the reminder of your processing time", which allows the OS to reschedule.
And since it doesn't give up any priority, it will then become more or less a "no operation" call if there are no other tasks with suitable priority ready to run so the rescheduling has no other suitable task to pick.
The a manual has a bit of a problem with how much time to spend on defining concepts like: - yield - time slice - quantum - priority - round robin - priority inversion - preemption - ...
if assuming that the reader isn't complementing the manual with a general text about operating system concepts and functionality.
Everyone might pick up on round robin being just a circular buffer - so sounds just about the same as for a serial port data buffer. But for an OS, it suddenly involves threads of same priority - and that are ready aka runnable. So it's a hard task to make the API documentation fully self-contained. There will always be things that can be improved. But there will also always be things that must be left for the reader to pick up by complementary sources.