Round-Robin scheduler in tickless mode Topic is solved

[Giovanni]

The current implementation has one important flaw: If a thread is preempted by an higher priority thread then, when it resumes execution, it gets a whole time quantum again. This can be a problem in some scenarios.

I am evaluating options, one timer per thread or time stamps or others.

In the meanwhile it will stay an optional add-on.

Giovanni

[Giovanni]

Hi,

I decided to not support the current implementation in chpreempt.c/.h, it will be removed from the repository but feel free to continue using it if it fits your needs.

My rationale:
- Working with virtual timers at context switch level kills performance and makes jitter much worse.
- The proposed solution is not a full solution to the general preemptive RR problem.
- Making a general solution would be even heavier, there are problems that the example implementation does not address.

Unresolved problems:
- Heavy implementation.
- The timer is reactivated for all threads, including idle, negating tickless mode. Ideally the timer should be activated only if there are "peer" threads.
- Time slices are not measured accurately if switches happen faster than a single tick.

Ideas for a future implementation:
- Time slices should be counted "in excess", intervals smaller than one tick should be considered as one tick.
- Add an attribute flags for threads that require RR handling, the flag would be set after creation. By default threads would not have this flag set, the timer would only be activated for threads with the flag set.
- Instead of using VTs add "channels" to the ST driver, a second channel could be used for RR, setting up an HW timer is faster than setting up a VT and it is constant time.
- The same timer could be used as "thread watchdog", threads exceeding the allowed time slice would trigger a system error. The two mechanisms should go together. This would be an excellent safety-related feature.

I consider this for RT6, it is late for RT5.

Giovanni

[Thargon]

Hi,

your considerations sound very reasonable. The cases where people need RR scheduling but are forced to use tickless mode for some reason should be quite rare, anyway. I am still happy that you already spend those efforts on the feature and your targeted solutions goes even further than my original intend was.
Maybe you can already start a thread "Ideas for RT6"

Thomas

[steved]

- Instead of using VTs add "channels" to the ST driver, a second channel could be used for RR, setting up an HW timer is faster than setting up a VT and it is constant time.
- The same timer could be used as "thread watchdog", threads exceeding the allowed time slice would trigger a system error. The two mechanisms should go together. This would be an excellent safety-related feature.

This sounds an excellent way to do it - in fact the only reason to flag a thread as needing RR support would be so that the "watchdog" timer knows whether to treat a timeout as an error or to simply reschedule the current thread. (This decision could be made via a configurable "hook" call, so that the coder could override the default decision making process)