Home |
RTKernel-32 Programming Manual Multitasking, Real-Time, and RTKernel-32 Alternate APIs for RTKernel-32 Avoid Polling Preemptive or Cooperative Multitasking? Starting Objects' Methods as Tasks Performance and Interrupt Response Times Task Switches in Cooperative Scheduling Using the FPU in Interrupt Handlers |
Avoid PollingPolling is often used when a task has to wait for something. For this purpose, some condition is continually tested in a loop until the expected event is recognized. In sequential programs, this is the only way to wait since the processor can't simply be paused. On the other hand, in a multitasking environment, this is a quite uncooperative behavior of a task, because precious CPU time that might otherwise be used more efficiently by other tasks is wasted. While a task has nothing to do, it should not be in the state Ready or Current. If the polled event is generated by another task, polling can be replaced by inter-task communications in all cases. The waiting task could, for example, block itself using RTKReceive. It can be reactivated when another task has recognized the event and transmits a corresponding message to the waiting task using RTKSend. For hardware events, interrupts offer the desired functionality. A task can be blocked in order to be reactivated by an interrupt as soon as the expected event occurs. All of the waiting time is available to other tasks in this manner and response time is optimal. Unfortunately, many I/O boards do not support interrupts (e.g., some digital I/O boards). In this case, polling cannot be avoided. However, polling should be as cooperative as possible, e.g., by providing CPU time to other tasks in each polling cycle using RTKDelay. Preemptive or Cooperative Multitasking?
|