Interesting that a higher priority task can essentially hog the entire CPU. From memory, the way AmigaOS handled scheduling was it would create a list of all tasks with their priorities, then iterate through the list, subtracting from the priority as it went. Only tasks with priority > 0 would be executed. Once all tasks had reached 0, the list would be repopulated with the original priority value and the process would repeat. This way, even the lowliest task would get some CPU allocation, but a task with priority 10 would get 10x the time slices of a task with priority 1 for example.
That means that high priority task need to cooperate by entering the delay stage in order to give lower priority tasks a chance to execute? That appears to be not very useful. There is no way to divide the available slots up to all the tasks and give them more or less time slices? Or is that a problem with the idea of an RTOS?
It’s good practice to assign the same priority to most of your tasks so that no task is starved. Interrupt handlers usually run intermittently at a higher priority.
