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
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.