Quote:
|
...This gets complicated by interruptions from higher priority tasks, and lower priority tasks are not completely starved by higher priority tasks. Usually, part of the scheduling algorithm includes how long a low priority task has been shutout of the CPU. If the CPU is full up with non-stop high priority tasks, a low priority task that has been waiting and waiting will eventually be allotted some time-essentially by having it's priority temporarily increased for a short time. There are also cases where a low priority task will lock an important system resource that a higher priority task is next in line for. In that case the low priority task will get it's priority temporarily bumped up to match the high priority task until the system resource is released, then it goes back to lowly priority status.
|
The above are pretty standard available features on any high quality commercial RTOS. But usually the RTOS is extremely flexible and configurable, and the app is responsible for specifying to the RTOS how it wants multitasking handled.
I wonder if what you described above is indeed the way the code generated by LabVIEW sets up the RTOS multitasking, assuming the programmer is using the 2010 FRC LabVIEW framework in the "standard" way (i.e. following the examples of the default code and templates).
~