2.5.2 Task-Independent Portion and Quasi-Task Portion

A feature of a task-independent portion (interrupt handlers, time event handlers, etc.) is that it is meaningless to identify the task that was running immediately prior to entering a task-independent portion, and the concept of “invoking task” does not exist. Accordingly, a system call that enters WAIT state, or one that is issued implicitly specifying the invoking task, cannot be called fromth a task-independent portion. Moreover, since the currently running task cannot bE_IDenti.ed in a task-independent portion, there is no task switching (dispatching).

If dispatching is necessary, it is delayed until processing leaves the task-independent portion. This is called delayed dispatching. If dispatching were to take place in the interrupt handler, which is a task-independent portion, the rest of the interrupt handler routine would be left over for execution after the task started by the dispatching, causing problems in case of interrupt nesting. This is illustrated in Figure 2.7.

In the example shown, Interrupt X is raised during Task A execution, and while its interrupt handler is running, a higher-priority interrupt Y is raised. In this case, if dispatching were to occur immediately on return from interrupt Y (1), starting Task B, the processing of parts (2) to (3) of Interrupt A would be put o. until after Task B, with parts (2) to (3) executed only after Task A goes to RUN state. The danger is that the low-priority Interrupt X handler would be preempted not only by a higher-priority interrupt but even by Task B started by that interrupt. There would no longer be any guarantee of the interrupt handler execution maintaining priority over task execution, making it impossible to write an interrupt handler. This is the reason for introducing the principle of delayed dispatching.

A feature of a quasi-task portion, on the other hand, is that the task executing prior to entering the quasi-task portion (the requesting task) can bE_IDenti.ed, making it possible to de.ne task states just as in the task portion; moreover, it is possible to enter WAIT state while in a quasi-task portion. Accordingly, dispatching occurs in a quasi-task portion in the same way as in ordinary task execution.

As a result, even though the OS extended part and other quasi-task portion is a nontask portion, its execution does not necessarily have priority at all times over the task portion. This is in contrast to interrupt handlers, which must always be given execution precedence over tasks.

The following two examples illustrate the difference between a task-independent portion and quasi-task portion.

  • An interrupt is raised while Task A (priority 8=low) is running, and in its interrupt handler (task-independent portion) tk_wup_tsk is issued for Task B (priority 2=high). In accord with the principle of delayed dispatching, however, dispatching does not yet occur at this point. Instead, after tk_wup_tsk execution, .rst the remaining parts of the interrupt handler are executed. Only when tk_ret_int is executed at the end of the interrupt handler does dispatching occur, causing Task B to run.
  • An extended system call is executed in Task A (priority 8=low), and in its extended SVC handler (quasi-task portion) tk_wup_tsk is issued for Task B (priority 2=high). In this case the principle of delayed dispatching is not applied, so dispatching occurs in tk_wup_tsk processing. Task A goes to READY state in a quasi-task portion, and Task B goes to RUN state. Task B is therefore executed before the rest of the extended SVC handler is completed. The rest of the extended SVC handler is executed after dispatching occurs again and Task A goes to RUN state.



  • If dispatching does not take place at (1), the remainder of the handler routine for Interrupt X ((2) to (3)) ends up being put o. until later.

Figure 2.7: Interrupt Nesting and Delayed Dispatching

Comments