-- SYSTEM SEGMENT
ROLE OF OPERATING SYSTEM IN TASK MANAGEMENT
Task switching without operating-system involvement is possible (though not necessarily advisable) in static systems. Consider the following two application-driven scheduling strategies for static systems:
1. A fixed sequence of tasks is defined, and each task, when ready to relinquish the processor, volun-tarily calls or jumps to the next task in sequence. Barring any errors, each task gets a share of processor time.
2. All tasks in the system service external events. The interrupt mechanism of the iAPX 286, by means of interrupt tasks, causes task initiation in real-time response to those events.
Strategy I is not viable in a highly protected system. Errors do happen. An erroneous program might easily skip a task entirely. A programming error that causes a tight loop in one task would prevent all other tasks from being serviced.
Strategy 2 can be adequate by itself for certain real-time systems with a static mix of tasks. Task switching by interrupt is usable in dynamic systems, too, but rarely do all tasks in a dynamic system deal exclusively with interrupts. Therefore, in dynamic systems, in highly protected systems, and in systems with tasks that do not provide real-time processing, the operating system may need to assist the processor with task switching.
4-4 121960-001
TASK MANAGEMENT
State Model of Task Scheduling
The role that the operating system must play in using the iAPX 286 task features is most conveniently expressed in terms of a state-transition model. To distinguish from the processing state of a task (as stored in the TSS), the term scheduling state is used here. Figure 4-2 illustrates the scheduling states that a task may assume and the events that may cause a change of state.
A RUNNING task is the one that the processor is executing. A RUNNING task continues to execute until
• It voluntarily gives up control because it needs to wait for some event, such as completion of an I/O operation, data from another program, or the end of a specific period of time.
• It is preempted, i.e., forced to give up control. The interrupt mechanism may cause preemption in order to execute an interrupt task, or the operating system may preempt periodically (via timer interrupt) to give another task a chance to receive its share of the processor's attention.
A WAITING task may be waiting for any of several events:
• Completion of a request to the OS for I/O
• A signal from another task
• Data from another task
• The end of a time-delay period
The READY state is really a special case of the WAITING state. A READY task is waiting for one specific event: the availability of a processor to execute it. A task becomes READY when first created.
A WAITING task becomes READY upon occurrence of the event (or events) for which it is waiting.
A RUNNING task becomes READY when preempted.
INITIATE
..
121960·22
Figure 4-2. Scheduling State Transition Diagram
TASK MANAGEMENT
Usually, termination of a task is possible regardless of its scheduling state; therefore, this diagram does not illustrate the transition to "terminated" state.
Interfacing with the Hardware Scheduler
Many applications of the iAPX 286 need both software scheduling (by the operating system) and hardware scheduling (by the interrupt mechanism), but when two schedulers work with the same set of tasks, you must ensure that they work together harmoniously. Figure 4-3 illustrates the additional complexity of dual schedulers.
Note that scheduling state under hardware scheduling is nearly analogous to scheduling state under software scheduling. The priority concept, often used in software scheduling, has its analog in the priority mechanism implemented by the interrupt controller. The priority of hardware-scheduled tasks relative to software-scheduled tasks is controlled by two factors:
• The CPU's interrupt-enable flag (IF), and the instruction's CLI (which clears IF) and STI (which sets IF)
• The 8259A Programmable Interrupt Controller, an LSI component that allows selective masking of interrupts so that software can prevent some external interrupts.
When IF is set, all hardware-scheduled tasks whose interrupts are not masked out have higher priority than all software-scheduled tasks. When IF is reset, all hardware-scheduled tasks have lower priority than the currently executing task. Only the operating system (CPL < = IOPL) has the right to execute
HARDWARE SCHEDULED
PREEMPTIVE INTERRUPT
INITIATE
IRET
DISPATCH
SOFTWARE SCHEDULED
121960-27
Figure 4-3. Expanded Scheduling State Transition Diagram
4-6 121960-001
TASK MANAGEMENT
eLI
and STI instructions due to the significant effect that priority setting has on correct, overall system operation.The ability for an interrupt handler to be an independent task not only protects the handler from the rest of the system but also permits greater flexibility in the kinds of functions an interrupt handler can perform. An interrupt handler that is a task can use operating system functions that might change its scheduling state. For example, if an interrupt handler requests the operating system to read a disk record, the operating system may change the interrupt handler task's scheduling state from RUNNING to 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 separately from the task that it interrupted.
The operating system must keep track of whether a task is attached to an interrupt (i.e., has a task gate in the IDT). Occurrence of an interrupt can at any time dispatch the task attached to the inter-rupt. This happens without intervention by the operating system; therefore, when a task calls on operat-ing system services, the operatoperat-ing system cannot assume that the calloperat-ing task is the same as the latest software-scheduled task.
An operating system can easily determine whether the current task is hardware or software scheduled if it associates with each task a Boolean that indicates whether the task was software-scheduled. The operating system must ensure that only one task at a time is so marked. The operating system can use the 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 can
Avoid executing a task that is awaiting an interrupt. A software-scheduled task cannot respond to an 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 schedules another task.
Decide what action to take when an interrupt-dispatched task calls on operating-system scheduling services. Such action might be to mask off the interrupt or to place a gate for a counting task in the IDT to mark lost interrupts.
When the operating system changes a task from hardware scheduling to software scheduling, it must update the chain of tasks that threads through TSSs. Every hardware scheduled task has a link in its TSS to the TSS of the interrupted task. If the system's interrupt structure permits nesting of inter-rupts, then the chain of interrupted tasks may be arbitrarily long. To change a task to software-scheduled mode, 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 State
In terms of the state model of scheduling, the operating system's job is to effect transitions between scheduling 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 express their scheduling needs by calls to operating system functions that indirectly relate to scheduling. For
TASK MANAGEMENT
TASK X
TSS TSS TSS TSS
FLAGS FLAGS FLAGS FLAGS
NT~l NT~l NT~l NT~l
BACK LINK
L /
BACK LINKL /
BACK LINKL /
BACK LINK CURRENTLYB EXECUTING
E TASK
F HARDWARE-SCHEDULED TASKS
0
---R SOFTWARE-SCHEDULED TASKS E
\
FLAGS NT~O TSS FLAGS NT~O TSS FLAGS NT~O TSS-:e-
BACK LINK*
BACK LINK.r-
BACK LINKCURRENT SOFTWARE-SCHEDULED TASK
TSS TSS TSS
FLAGS FLAGS FLAGS
NT~l NT~l NT~l
BACK LINK
L /
BACK LINK~
BACK LINK CURRENTLY EXECUTINGA TASK
F HARDWARE-SCHEDULED TASKS
T
---E SOFTWARE-SCHEDULED TASKS
R TASK X