2.2.1 Task States
Task states are classi.ed primarily into the .ve below. Of these, Wait state in the broad sense is further classi.ed into three states. Saying that a task is in a Run state means it is in either RUN state or READY state.
The task is currently being executed. When a task-independent portion is executing, except when otherwise specified, the task that was executing prior to the start of task-independent portion execution is said to be in RUN state.
The task has completed preparations for running, but cannot run because a task with higher precedence is running. In this state, the task is able to run whenever it becomes the task with the highest precedence among the tasks in READY state.
The task cannot run because the conditions for running are not in place. In other words, the task is waiting for the conditions for its execution to be met. While a task is in one of the Wait states, the program counter and register values, and the other information representing the program execution state, are saved. When the task resumes running from this state, the program counter, registers and other values revert to their values immediately prior to going to the Wait state. This state is subdivided into the following three states.
Execution is stopped because a system call was invoked that interrupts execution of the invoking task until some condition is met.
Execution was forcibly interrupted by another task.
The task is in both WAIT state and SUSPEND state at the same time. WAIT-SUSPEND state
results when another task requests suspension of a task already in WAIT state T-Kernel makes a clear distinction between WAIT state and SUSPEND state. A task cannot go to SUSPEND state on its own.
The task has not yet been started or has completed execution. While a task is in DORMANT state, information presenting its execution state is not saved. When a task is started from DORMANT state, execution starts from the task start address. Except when otherwise specified, the register values are not saved.
A virtual state before a task is created, or after it is deleted, and is not registered in the system.
Depending on the implementation, there may also be transient states that do not fall into any of the above categories (see section 2.5 on page 12).
When a task going to READY state has higher precedence than the currently running task, a dispatch may occur at the same time as the task goes to READY state and it may make an immediate transition to RUN state. In such a case the task that was in RUN state up to that time is said to have been preempted by the task newly going to RUN state. Note also that in explanations of system call functions, even when a task is said to go to READY state, depending on the task precedence it may go immediately to RUN state.
Task starting means transferring a state from DORMANT state to READY state. A task is therefore said to be in “started” state if it is in any state other than DORMANT or NON-EXISTENT. Task exit means that a task in started state goes to DORMANT state.
Task wait release means that a task in WAIT state goes to READY state, or a task in WAIT-SUSPEND state goes to SUSPEND state. The resumption of a suspended task means that a task in SUSPEND state goes to READY state, or a task in WAIT-SUSPEND state goes to WAIT state.
Task state transitions in a typical implementation are shown in Figure 2.1. Depending on the implementation, there may be other states besides those shown here. A feature of T-Kernel is the clear distinction made between system calls that perform operations a.ecting the invoking task and those whose operations a.ect other tasks (see Table 2.1). The reason for this is to clarify task state transitions and facilitate understanding of system calls. This distinction between system call operations in the invoking task and operations a.ecting other tasks can also be seen as a distinction between state transitions from RUN state and those from other states.
WAIT state and SUSPEND state are orthogonally related, in that a request for transition to SUSPEND state cannot have any e.ect on the conditions for task wait release. That is, the task wait release conditions are the same whether the task is in WAIT state or WAIT-SUSPEND state. Thus even if transition to SUSPEND state is requested for a task that is in a state of waiting to acquire some resource (semaphore resource, memory block, etc.), and the task goes to WAIT-SUSPEND state, the conditions for allocation of the resource do not change but remain the same as before the request to go to SUSPEND state.
The reason the T-Kernel speci.cation makes a distinction between WAIT state (wait caused by the invoking task) and SUSPEND state (wait caused by another task) is that these states sometimes overlap. By distinguishing this overlapped state as WAIT-SUSPEND state, the task state transitions become clearer and system calls are easier to understand. On the other hand, since a task in WAIT state cannot invoke a system call, di.erent types of WAIT state (e.g., waiting for wakeup, or waiting to acquire a semaphore resource) will never overlap. Since there is only one kind of wait state caused by another task (SUSPEND state), the T-Kernel speci.cation treats overlapping of SUSPEND states as nesting, thereby achieving clarity of task state transitions.
Operations in invoking task (transitions from RUN state)
Operations on other tasks (transitions from other states)
Task transition to a wait state (including SUSPEND)
tk_slp_tsk
tk_sus_tsk
RUN
READY
WAIT
WAIT
SUSPEND
WAIT-SUSPEND
Task exit
tk_ext_tsk
tk_ter_tsk
RUN
READY
WAIT
DORMANT
DORMANT
Task deletion
tk_exd_tsk
tk_del_tsk
RUN
DORMANT
NON-EXISTENT
NON-EXISTENT
Table 2.1: State Transitions Distinguishing Invoking Task and Other Tasks
Figure 2.1: Task State Transitions
Comments