If the operating system is to support real-time applications, or even just interactive applications, there is little choice but to allow a programmer to make some assumptions about the rate of execution of a process. It is also necessary to allow the rate of execution to be influenced by the programmer.
Most operating systems allow priorities to be attached to processes, and some implement feed-back schemes that dynamically adjust the priorities of processes. While workable, and often successful, this approach does suffer from the drawback that priorities must be chosen and controlled carefully. When the number of real-time processes become large, it becomes very difficult to use priorities with predictable effect.
A simpler approach is to allow the rate of execution of a process to be specified directly, rather than be influenced indirectly via priorities. For example, the speed of a processor can be rated on some absolute scale and the rate of execution of a process expressed as a number on the same scale, with the following interpretation: Let Y be the speed of the processor and X the desired rate of execution of a process. The process should then receive at least X/Y of the processor's cycles, say every 100 milliseconds, while the process remains ready to execute.
Of course, to guarantee that a process will progress at least as rapidly as at its desired rate of execution, the sum of the rates of all the processes that can be ready at the same time must not exceed the speed of the processor. However, it should be easier for a real-time application designer to ensure that this is true, than it would be to ensure that a set of priorities will result in the desired progress by each process.
To aid real-time application designers further, an operating system should also be able to distinguish among ``real-time'' and ``ordinary'' processes, with real-time processes preempting ordinary processes. A real-time application designer then need not take non-real-time processes into account at all.
