Processor hogging and round robin scheduling

[steved]

I've come across a possible case where it looks as if processor hogging can occur in tickless mode, and wanted to check whether I've understood Chibi's operation correctly.

I'm running Chibi (17.6.0) in tickless mode, and have multiple worker threads of equal priority, which will all be idle for most of the time, but whose tasks could on occasion be relatively long-running.
I want to ensure that these threads don't starve other threads, and each other, of processor time.
I can reduce the priority of the worker threads to solve part of the problem.
However it looks as if when execution of a higher priority thread is complete, execution passes back to the worker thread which was preempted, rather than passing to another thread of the same priority (which seems more desirable in this case).

I realise I could disable tickless mode, but would prefer to keep the resolution of the timing functions, and avoid the overhead of timer interrupts; especially since this won't be a problem most of the time.

Potentially I could call chThdYield() in appropriate places in the worker threads; however it would complicate programming, and wouldn't share processor time among the worker threads, because of the way the scheduler works.

Line 598 in chsch.c is:
otp = chSchReadyAheadI(otp);

It seems to me that I could achieve what I want by simply changing it to:
otp = chSchReadyI(otp);

[Scope for a name change to chSchReadyBehindI()??]

Is this a reasonable thing to consider? Or would there be other implications? Is there a better way to solve the problem? Or have I just misunderstood how things work?

[Giovanni]

Hi,

It used to work exactly as you wanted up in old versions, threads at equal priority were rotated each time there was a context switch for whatever reason.

The current implementation is:
- Threads can consume all their time slice in round robin mode without having their slot reduced by external causes.
- In case the preemptive round robin is disabled (tickless mode) then the rotation only happens on chThdYield().

Now non-preemptive round robin is purely collaborative, if preemption is disabled then the time for yielding could be synchronized on system time stamps or using a virtual timer setting a global flag and then restarting itself.

The rationale is predictability, the old behavior was not predictable being affected by external causes (unrelated threads or ISRs). The new system is very reliable for time division.

Giovanni

[steved]

The rationale is predictability, the old behavior was not predictable being affected by external causes (unrelated threads or ISRs). The new system is very reliable for time division.

I suspected there was a good reason. In my case the lack of predictability would most likely not be a problem; it could be managed with thread priorities.
I'll have a go at making chThdYield() accessible; unfortunately these worker threads are running some third party software where I have less control over what happens when.