iAPX 286 Operating System Writers Guide 1983

TASK MANAGEMENTeLI and STI instructions due to the significant effect that priority setting has on correct, overallsystem operation.The ability for an interrupt handler to be an independent task not only protects the handler from therest of the system but also permits greater flexibility in the kinds of functions an interrupt handler canperform. An interrupt handler that is a task can use operating system functions that might change itsscheduling state. For example, if an interrupt handler requests the operating system to read a diskrecord, the operating system may change the interrupt handler task's scheduling state from RUNNINGto WAITING while the I/0 operation takes place. (Other tasks may then execute in the meantime.)If the interrupt handler were a procedure instead of a task, it would be difficult to identify it separatelyfrom the task that it interrupted.The operating system must keep track of whether a task is attached to an interrupt (i.e., has a taskgate in the IDT). Occurrence of an interrupt can at any time dispatch the task attached to the interrupt.This happens without intervention by the operating system; therefore, when a task calls on operatingsystem services, the operating system cannot assume that the calling task is the same as the latestsoftware-scheduled task.An operating system can easily determine whether the current task is hardware or software scheduledif it associates with each task a Boolean that indicates whether the task was software-scheduled. Theoperating system must ensure that only one task at a time is so marked. The operating system can usethe STR instruction to identify the current task. If the current task is not marked as software-scheduled,then the interrupt mechanism must.have dispatched it.By knowing whether a task is attached to an interrupt, the operating system canAvoid executing a task that is awaiting an interrupt. A software-scheduled task cannot respond toan interrupt. An exception occurs when an interrupt attempts to invoke a busy task.• Avoid preempting an executing interrupt task. That task should finish before software schedulesanother task.Decide what action to take when an interrupt-dispatched task calls on operating-system schedulingservices. Such action might be to mask off the interrupt or to place a gate for a counting task in theIDT to mark lost interrupts.When the operating system changes a task from hardware scheduling to software scheduling, it mustupdate the chain of tasks that threads through TSSs. Every hardware scheduled task has a link in itsTSS to the TSS of the interrupted task. If the system's interrupt structure permits nesting of interrupts,then the chain of interrupted tasks may be arbitrarily long. To change a task to software-scheduledmode, the operating system must take these actions (as figure 4-4 illustrates):Reset the nested-task flag (NT) of the current task.Nullify the back-link field in the current TSS (as insurance in case it is ever used).Dispatch the prior task on the back-link chain.Changing Scheduling StateIn terms of the state model of scheduling, the operating system's job is to effect transitions betweenscheduling states according to the expressed needs of individual tasks and of the application as a whole.In many cases, applications drive the scheduling activities of the operating system. Applications expresstheir scheduling needs by calls to operating system functions that indirectly relate to scheduling. For4-7 121960-001