|
| Home |
|
|
What is Multitasking?A thread (also called a task) is a sequential path of execution. The discrete statements of a thread are processed sequentially according to the semantics of C, C++, or Pascal. The term multitasking means that several sequential tasks are processed in parallel. However, on single processor systems, several tasks cannot run at the same time; therefore, task switches must be performed. This is the job of a multitasking system like RTKernel-32. In many cases, tasks cannot run completely independently of each other, but are expected to cooperate. For example, it may be required that a certain task can only continue to run after another task has completed a certain operation. In such a case, the tasks involved must be synchronized, i.e., the parallelism of tasks is restricted again. Synchronization can be accomplished using inter-task communication. For a good understanding of parallel programming, it is important to be aware of the different requirements of multitasking systems. Below, the most important differences between time sharing and real-time systems are discussed. Time SharingTime sharing utilizes multitasking for the purpose of sharing a high performance computer among several users (or batch jobs) at the same time. In general, tasks run largely independently of each other in time sharing systems. Therefore, inter-task communication is only offered in a simple fashion. One of the most popular time sharing systems is Unix. It was developed when the processing power of the available computer was smaller than that needed for the job. Consequently, the multitasking system had to share the scarce resource "processing power" as "fairly" as possible among competing tasks. However, it should be noted that system throughput is usually degraded by multitasking in such systems, because the scheduling overhead is significant. Under Unix, for example, it is possible that two compute-bound programs each runs a minute when it is the only program running; however, running in parallel, they would need 2.5 minutes. Parallel processing may be more fair (User 1 and User 2 have to wait equally long for their job to finish), but is usually less efficient. Real-Time SystemsReal-time systems satisfy a completely different set of requirements. A real-time system must never be overloaded. As soon as no more processing power is available, real-time response cannot be sustained. For example, a situation with real-time requirements might be: a meter generates data every second. The data must be collected, processed, and stored by the computer. If processing a data record requires more than a second on the target computer, the system is overloaded and real-time response cannot be sustained. Real-time systems are not concerned about "fairness". Tasks have priorities which must be obeyed strictly. A task with a high priority can take away CPU time from another task with a lower priority at any time without "being fair" to the other task. Since overloading is ruled out, tasks having low priorities will sooner or later also receive CPU time. Real-time systems are furthermore characterized by the requirement that they have to react to events within a predetermined - usually short - time span. External events are processed using interrupts whenever possible. Thus, the most stringent real-time requirements apply to interrupt handlers. Therefore, real-time systems must have a low interrupt latency (the time between the hardware interrupt signal and execution of the first statement of the interrupt handler). For the task response time, the cases of cooperative and preemptive scheduling must be distinguished. In preemptive scheduling, the task response time to interrupts is mainly the interrupt latency and the task switch time. In cooperative scheduling, the maximum time span between two kernel calls is added. Cooperative and Preemptive MultitaskingPreemptive multitasking means that task switches can be initiated directly out of interrupt handlers. With cooperative (non-preemptive) multitasking, a task switch is only performed when a task calls the kernel, i.e., it behaves "cooperatively" and voluntarily gives the kernel a chance to perform a task switch. Example:A receive interrupt handler for a serial port writes data to a mailbox. If a task is waiting at the mailbox, it is immediately activated by the scheduler during preemptive scheduling. In cooperative scheduling, however, the task is only brought into the state "Ready". A task switch does not immediately take place; after the interrupt handler has completed, the task having been interrupted continues to run. Such a "pending" task switch is performed by the kernel at some later time, as soon as the active task calls the kernel. RTKernel-32 supports both cooperative and preemptive scheduling. The preconfigured default is cooperative scheduling for the single CPU scheduler and preemptive for the multiprocessor kernel.
|
