Good day,

I have read the info pages on the site, but those regarding the scheduler algorithm look very vague to me.
So, FreeRTOS implements a dynamic priority algorithm for different priority tasks and round robin when tasks have the same priority.
I concluded, studying it's operation, that if only static priority assigment would be used ( no vTaskPrioritySet() ), we could state that Rate-Monotonic Scheduler algorithm is used.

Priority Inversion cases handled with portENTER_CRITICAL() and portEXIT_CRITICAL() and mutexes?

Pleaese correct me if i'm wrong.


Beast Regards,
Alex

First, portENTER_CRITICAL and portEXIT_CRITICAL do nothing for Priority Inversion to my knowledge, it is solely handled by the mutex code by temporarily raising a tasks priority if it holds a mutex that a higher priority task wants. (And I believe it makes the assumption that said task will not get a second priority boost while this boost is occuring).

I would not assign the blanket description of the Scheduler as "Rate-Monotonic" as that description means that the tasks with the shortest periods get the highest priority. While the programs CAN assign the priorities in this manner, freeRTOS does not enforce this, One reason is that sometime you can have tasks with low processing rates, but short deadlines (when data arrives, it needs to be processed NOW, but data comes infrequently).

A better description is that FreeRTOS uses Hard Priorities (a lower priority task will never get time, if a higher priority task is ready) with a simple Round Robin scheduling for tasks at the same priority. This leads to the possibility of lower priority tasks getting starved for time if the higher priority tasks use it all, and that tasks at the same priority, while they share time, may not all get equal time. The issue is that if one task uses up most of a tick, and then blocks, the next task at that priority only gets a part of the tick to process before the timer tick arrives and forces a reschedule. A more complicated system might measure how much time has been used (sub tick interval) and schedule based on lowest recent usage, not longest since ran to be more "fair" at this time allocation (at the cost of more overhead and less portability).