T-Kernel Specification (1.B0.02)

12 CHAPTER 2. CONCEPTS UNDERLYING THE T-KERNEL SPECIFICATION
handlers can be designed for direct starting, basically without OS intervention, or for starting via a
high-level language support routine.
2.4 Task Exception Handling
The T-Kernel specification defines task exception handling functions for dealing with exceptions. Note
that exceptions other than those in the CPU are treated as interrupts.
A task exception handling function is one that invokes a system call requesting task exception handling,
interrupts execution by the designated task, and runs a task exception handler. Execution of the task
exception handler takes place in the same context as the interrupted task. Upon return from the task
exception handler, the interrupted processing continues. One task exception handler per task can be
registered with an application.
2.5 System States
2.5.1 System States While Nontask Portion Is Executing
When programming tasks to run on T-Kernel, the changes in task states can be tracked by looking at
a task state transition diagram. In the case of routines such as interrupt handlers or extended SVC
handlers, however, the user must perform programming at a level closer to the kernel than tasks. In this
case consideration must be made also of system states while a nontask portion is executing, otherwise
programming cannot be done properly. An explanation of T-Kernel system states is therefore given
here.
System states are classified as in Figure 2.6. Of these, a “transient state” is equivalent to OS running
state (system call execution). From the standpoint of the user, it is important that each of the system
calls issued by the user be executed indivisibly, and that the internal states while a system call is
executing cannot be seen by the user. For this reason the state while the OS running is considered a
“transient state” and internally it is treated as a blackbox. In the following cases, however, a transient
state is not executed indivisibly.
• When memory is being allocated or freed in the case of a system call that gets or releases memory
(while a T-Kernel/SM system memory management function is called).
• In a virtual memory system, when nonresident memory is accessed in system call processing.
When a task is in a transient state such as these, the behavior of a task termination (tk ter tsk) system
call is not guaranteed. Moreover, task suspension (tk sus tsk) may cause a deadlock or other problem
by stopping without clearing the transient state. Accordingly, as a rule tk ter tsk and tk sus tsk
cannot be used in programs. These system calls should be used only in a subsystem such as a virtual
memory system or debugger that is so close to being an OS that it can be thought of as part of the OS.
A task-independent portion and quasi-task portion are states while a handler is executing. The part of
a handler that runs in a task context is a quasi-task portion, and the part with a context independent
of a task is a task-independent portion. An extended SVC handler, which processes extended system
calls defined by the user, is a quasi-task portion, whereas an interrupt handler or time event handler
triggered by an external interrupt is a task-independent portion. In a quasi-task portion, tasks have the
same kinds of state transitions as ordinary tasks and system calls can be issued even in WAIT state.
A transient state, task-independent portion, and quasi-task portion are together called a nontask portion.
When ordinary task programs are running, outside of these, this is “task portion running” state.
Copyright c○ 2002, 2003 by T-Engine Forum
T-Kernel 1.B0.02