Exceeding the periods of tasks
Observance of the periods configured for the tasks depends on various factors, including the effective workload assigned to the task (code 1131 to run), the load and period of tasks with a higher priority, etc.It is therefore possible for a task to fail to run in observance of the times configured, more or less frequently and especially during the program development phase, when these conditions have to be properly checked and calibrated.Allowing for the controls configured on run times (see dedicated paragraph), the system continues its operation without stopping. Each task will automatically take the time needed to complete its running cycle, even exceeding the run time configured.In these cases, when the “prolonged” cycle has been completed, the tasks will usually be suspended and be reactivated on the next multiple of the period configured.Obviously a similar condition, especially if frequent and particularly costly, triggers a decline in control, in which tasks with a lower priority will have less UPC time available until the limit condition for which they might not be run.
Above is the same time diagram presented before, in which the FAST task run time is increased. Note that the task extends beyond its period and skips the running of a cycle, so it is regularly suspended to start up again synchronously at the initial instant of the first next theoretic period.The event has unavoidable consequences on the other system tasks: the NORMAL task undergoes a major start delay and consequently has less UPC time available; it cannot be completed within the period configured and proceeds. At the end, it is suspended, and starts again together with the next theoretic period. Note that, in addition to a longer initial delay, it is interrupted several times by the FAST task, which further reduces the time available, delaying the completion time.The SLOW task undergoes the following: its initial delay becomes considerable, taking the initial instant almost to the start of the next period. In this case we assume that the SLOW task is short and that it can be completed with the allotted period. Note, in the example used, the effective period measurements and run time of the SLOW task, if measured at the real start of running instead of the theoretic moment.During this phase, no UPC time is granted to tasks with a lower priority. These tasks are necessarily delayed and compressed into possible gaps: this usually multiplies the delays by the tasks of greater priority towards those of lower priority.See how the BACKGROUND task is delayed and its running slots are reduced.It is easy to imagine the effects that this kind of operation can have on the system when it occurs repeatedly and when it is triggered by the increase in run time not of one but of several tasks, even at the same time.
Above is the same time diagram presented before, in which the FAST task run time is increased. Note that the task extends beyond its period and skips the running of a cycle, so it is regularly suspended to start up again synchronously at the initial instant of the first next theoretic period.The event has unavoidable consequences on the other system tasks: the NORMAL task undergoes a major start delay and consequently has less UPC time available; it cannot be completed within the period configured and proceeds. At the end, it is suspended, and starts again together with the next theoretic period. Note that, in addition to a longer initial delay, it is interrupted several times by the FAST task, which further reduces the time available, delaying the completion time.The SLOW task undergoes the following: its initial delay becomes considerable, taking the initial instant almost to the start of the next period. In this case we assume that the SLOW task is short and that it can be completed with the allotted period. Note, in the example used, the effective period measurements and run time of the SLOW task, if measured at the real start of running instead of the theoretic moment.During this phase, no UPC time is granted to tasks with a lower priority. These tasks are necessarily delayed and compressed into possible gaps: this usually multiplies the delays by the tasks of greater priority towards those of lower priority.See how the BACKGROUND task is delayed and its running slots are reduced.It is easy to imagine the effects that this kind of operation can have on the system when it occurs repeatedly and when it is triggered by the increase in run time not of one but of several tasks, even at the same time.