Dear all,
I have to work with RL-RTX, and I have first look at the RTX traffic example. There is something I do not understand about task switching. Some years ago, I was working on a home-made RTOS, and the switch from a task to another could only occured at "kernel time" (that means at every time tick). If a task only used 50% of a tick time, the rest of the tick time was for "idle", and next task only starts after the kernel time at the end of the tick. With the traffic example, it seems that when a task is delayed (by instance with os_dly_wait) during a tick time, another "ready" task can directly start, without waiting for the end of the tick time when the kernel will run. Is it right? If yes, can you explain me how it works? (maybe the kernel runs to switch the tasks even if the time tick is not finished?) Thanks ! Best regards
When a task is "blocked" for some reason the next task in the ready queue is run. The idle task is considered just another task that can run that is always ready. Task switching is not actually tied to the timer tick. There are cases that the timer tick MAY cause a task switch (a delay terminates, other waiting items timeout, but these timeouts are process, the tasks are placed in the ready queue and when the tick processing is over the highest priority ready task is run. The OS actually does not do a full saving of state of the task unless there is actually a task switch.
Thank you. In my (old) opinion, the RT kernel had to choose at each end of tick what to do for the next one, i.e. looking for the ready task that has to run, and eventually apply a task switching. If "task switching is not actually tied to the timer tick", I understand that kernel job is less complex and is only about delay stuff. The task switching is controled by a "ready queue", but this queue is updated at any time, and not only at the tick time, right? (I am not sure to understand then "who" update this queue: the delay fonction by instance?).
The OS will reevaluate what task to run whenever a thread or ISR generates a signal or posts a mail. Or whenever the system timer ticks the last tick of a time slice. Or when a thread donates time. Or when a sleep timer ends.
So it isn't just at the end of a time slice that the OS can perform rescheduling. The OS kernel is an event processor. You send it an event when you post a mail. The ISR sends it events by using the signal or mailbox functions. The system timer sends it events. Any event is as good as another for rescheduling what thread to run.
As a footnote. If you have a very low-resolution system timer so you time slice on every system timer tick then a thread that donates time after 95% of the system tick can result in the next thread only getting 5% of a time slice before the timer ticks again. If the OS has access to maybe a prescaler counter it may view it could correct this issue by giving the next thread 105% time i.e. by setting a flag that the next system tick shouldn't result in a task switch. If the OS doesn't have access to any prescaler, then it will either have be extremely unfair or busy-loop until the next timer tick and not switch to the next thread until the system tick happens. So old OS with low-resolution system timers had a hard time trying to be fair.
A normal workaround would be to program the system timer so a task switch happens on overflow. And an early task switch is then handling by clearing the timer to restart a full task switch. But that makes it hard to use the same timer for measuring delays. Especially when the processor registers also quickly overflows.
But not many people selects 8-bit or even 16-bit processors anymore if they want to run an RTOS.