That's true - high priority tasks have more possibilities to run then lower once.
But I'm talking about one very often used case - high priority tasks finished their job, so they try to bring some "compassion" to low priority tasks. This could not be done with OS_Yield(). I don't know how to explain you - it's a case of "social injustice". Some tasks want to bring the control to lower priority tasks, but they can't , doesn't matter that there is enough time. I mean - OS_Yield is a way to bring control to equal or higher priority tasks, but not to lower one. So, it's easy now to see the "white spot" - absence of command to bring easily the control to low priority tasks, without carrying about priorities , etc.
So, you can mark - there is no quick and simple way in SALVO to bring fresh air to low priority tasks. Well - OS_Delay is OK, but this will slow down the high priority tasks. Wait some semaphore is OK too - but need resources. The way to increase slowly the priority is too complicated.
I'm talking about some totally new function, that changes for a while the hierarchy of tasks, something like "thanksgiving day" when rich people share their money with beggar. One of the way is to delay the checking in of the OS_Yield task into the queue. So there should be add new state - Running, Waiting.... Refreshing (Compassion). Maybe "compassion" is the exactly word for such state. Because the task doesn't need to bring any time to anybody else lower then it. So, it's only a "good will".
Here is something that came to me in the last moment (excuse me for that the letter has little strange structure - it's because I didn't send it and applied the new ideas to old letter - became little twisted). What about:
Description - the task contex switch to the kernel and waits "number" times to run OSShed. It's absolutely equal to OS_Delay, with this small difference, that the counts are taking not from OSTimer, but from OSSched(). Or, it even could be imitate with current SALVO with OS_Delay, if OSTimer() is called from the main loop, immediately before or after OSShed. In this case OSTimer will be run with frequency of calling of OSShed.
So, if we have similar function in SALVO, let's think more - what about second OSTimer().. let's say OSTimer1()? If the user has possibility to call more then 1 OSTimer function it will be possible to call it from OSShed too - this will cover all noise around "compassion" problem of the high priority tasks, without losing their priority and response speed. Imagine that you can call
OS_Delay(number_of_OSShed_calls, channel_1, _Label);
The new modified OS_Delay could do the priority "compassion" issue, if channel 2 is called just before OSShed with OSTimer1(). And the now existing OSTimer will become OSTimer0().
If there are 4 low priority tasks with equal low priority, you can call OS_Delay(4, channel_1, _Label) and this will ensure that all tasks will get fresh air, right?
Now, new horizons appeared for the applications of the functions. One if the Interval - you can very simply make any interval function, if you call OSTimer1 from TMR1 or TMR2 with desired baud rate. It will produce high accuracy delays, with any frequency and phase.
As you see the function became OS_Delay, the existing OS_Delay with small "improvements" and the OSTimer1() - second timer function. Even you can think about OSNUMBER_OF_TIMERS settings in salvocfg.h ! I don't insist to have multiple OSTimer.. only 2 are enough to cover the "compassion" issue of the tasks, something like twisters - you know 2 kids are growing better then single one :-) Well, two kids need more resources (money, attention) from the parents (my own experience) as well.
So the issue can flow into new issue - "OS_Delay() improvements" or "The lost twister of OSTimer was finally found from FBI", or the current could be renamed.
I got these ideas from one of my projects where I marked that high priority tasks have one very bad character - they don't have "human compassion" - even if they have time and they could bring the time to low priority task, they don't do this. In fact with current functions there is no simple way to do this.
Other approach - define new state:
Such new state of the task doesn't change it's priority, but it eliminate high priority tasks from the "game" for some time. In this time low priority tasks could take control and celebrate.
In my opinion the approach is to create new state, similar to eligible, but the task should wait some number of OSSched() calls to become automatically eligible.
I have to think more about this, as I told you, this is only initial idea. Maybe there are possible good solutions with current SALVO functions. But this is one deep problem - the using of OS_Yield with different priority tasks.
I'll keep you in touch if something new passes trough my head :-)