The basic logical unit of concurrent program execution is called a "task." Whereas the code in one task is executed in sequence, codes in different tasks can be executed in parallel. This concurrent processing is a conceptual phenomenon, from the standpoint of applications; in actual implementation it is accomplished by time-sharing among tasks as controlled by the kernel.
A task that invokes a system call is called the "invoking task."
The switching of tasks executed by the processor is called "dispatching" (or task dispatching). The kernel mechanism by which dispatching is realized is called a "dispatcher" (or task dispatcher).
The processing to determine which task to execute next is called "scheduling" (or task scheduling). The kernel mechanism by which scheduling is realized is called a "scheduler" (or task scheduler). Generally a scheduler is implemented inside system call processing or in the dispatcher.
The environment in which a program runs is generally called "context." For a context to be called identical, at the very least the processor operation mode must be the same and the stack space must be the same (part of the same contiguous area). Note that context is a conceptual entity from the standpoint of applications; even when processing must be executed in independent contexts, in actual implementation both contexts may sometimes use the same processor operation mode and the same stack space.
The relationship among different processing requests that determines their order of execution is called "precedence." When a higher-precedence process becomes ready for execution while a low-precedence process is in progress, as a general rule the higher-precedence process is run ahead of the other process.
Priority is a parameter assigned by an application to control the order of task or message processing. Precedence, on the other hand, is a concept used in the specification to make clear the order in which processing is to be executed.
Precedence among tasks is determined based on task priority.
The standard interfaces for calling functions provided by μT-Kernel from applications or middleware are collectively called API (Application Program Interface). In addition to system calls that directly call kernel functions, APIs include functions implemented as extended SVCs, macros, and libraries.
Kernel in the narrow sense of the word refers to the core part of μT-Kernel by excluding the parts implemented as subsystem or device drivers. In the broader sense of the word, it refers to the whole of μT-Kernel.
Generally speaking, μT-Kernel/OS and μT-Kernel/DS are usually implemented as kernel in the narrow sense of the word,kernel, μT-Kernel/SM may be implemented as an extension of μT-Kernel/OS by using the subsystem function of μT-Kernel/OS. In this case, μT-Kernel/SM is not part of the OS kernel in a narrow sense.
μT-Kernel or μT-Kernel itself refers to a combination of μT-Kernel/OS, μT-Kernel/SM, and μT-Kernel/DS.
That something is implementation-defined means that something is not standardized in the T-Kernel specification and should be defined for each implementation. The specifics of the implementation should be described clearly in the implementation specifications. In application programs, the portability for the portion dependent on implementation-defined items is not assured.
That something is implementation-dependent means that in the T-Kernel specification, the behavior of something varies according to the target systems or system operating conditions. The behavior should be defined for each implementation. The specifics of the implementation should be described clearly in the implementation specifications. In application programs, the portion dependent on implementation-dependent items needs to be modified when porting in principle.