T-Kernel Specification (1.B0.02)

2.2. TASK STATES AND SCHEDULING RULES 7
(e) NON-EXISTENT state
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 affecting
the invoking task and those whose operations affect 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 affecting other tasks can also be seen as a
distinction between state transitions from RUN state and those from other states.
Additional Note
WAIT state and SUSPEND state are orthogonally related, in that a request for transition to SUSPEND
state cannot have any effect 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.
Rationale for the Specification
The reason the T-Kernel specification 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, different 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 specification treats overlapping of SUSPEND states as nesting,
thereby achieving clarity of task state transitions.
Copyright c○ 2002, 2003 by T-Engine Forum
T-Kernel 1.B0.02