|
| Home |
|
|
Avoid Time SlicingTime slicing is a technique that originated in time sharing systems. In section Multitasking, Real-Time, and RTKernel-32, the differences between time sharing systems and real-time systems were discussed briefly. Actually, time slicing only makes sense if your tasks don't have to meet real-time requirements, never have to wait for something, and can run largely independently of each other. In this case, however, you could let the tasks run sequentially and thus avoid the overhead incurred by RTKernel-32. The fairness strived for by time sharing systems cannot be attained by RTKernel-32 anyhow. The simplest definition of fairness would be that CPU time must be shared evenly among all tasks. (Systems like Unix use a much more elaborate definition of fairness.) The scheduling rules of RTKernel-32 can only achieve this if all tasks of a program have the same priority, can run completely independently of each other, and never block themselves. If these conditions are not met, time slicing will only guarantee that each task receives CPU time in the long run - when and how much is, in general, indeterminate. In many applications, RTKDelay(0) can be a feasible alternative to time slicing. Using RTKDelay(0), round-robin scheduling (tasks are activated in turn) can be implemented easily. Assume the following problem shall be solved: Two tasks must recognize an event using polling. The polling cycle must be as short as possible. A simple solution would be to switch among tasks using time slicing. In this case, however, the polling cycle would be 55 milliseconds in the worst case. The timer interrupt rate could be increased, thus achieving a polling cycle of a few milliseconds. However, it would be much more elegant to call RTKDelay(0) in each polling cycle. Each task involved could then process a polling cycle without being disrupted and afterwards allow the next task to run. It would not even be required to activate preemptions or time slicing. Assuming the polling itself requires only 10 microseconds, about 20,000 cycles per second could be achieved on an 80386/20. This algorithm would also ensure fairness, even if more than two tasks participated.
|
