Embedded.com – Using design patterns to identify and partition RTOS tasks: Part 1

… any operation whose deadline is measured in milliseconds—not microseconds—is a candidate for a high priority task. Assuming that your system has some serious computing to do at least once in a while, then anything that your system must do in milliseconds will miss its deadline if it has to wait for the serious computing to complete. (If your system never has any time-consuming CPU activity, then you’re unlikely to have any deadline problems anyway and might well stick to a polling loop for your code.)Operations whose deadlines are measured in microseconds typically end up in ISRs in any case. Some examples of things that fall into the millisecond category are (1) Responding after a complete message has been received from another system over the serial port; (2) Constructing a suitable response to a network frame and sending it; and , (3) Turning off the valve when sensors tell us that we’ve added enough of some ingredient to a manufacturing mixture.

CPU Hog Pattern.
Any operation that takes up an amount of CPU time measured in seconds, or perhaps a large number of milliseconds, is a candidate to be moved into a low priority task. The trouble with CPU-intensive operations is that they endanger every deadline in the system. Creating a separate, low-priority task for a CPU-intensive operation gets rid of the interference. Note that of course moving such an operation into a low priority task is the equivalent of moving everything else into a higher priority task. However, the “put the CPU-hogging operation into a low priority task” is often an obvious pattern