As mentioned above, processes may possess different priorities. OpenVMS always schedules the highest-priority computable process for execution.
Normal process priorities are from 0 through 15, with the default interactive priority at 4. Higher numbers represent higher priorities. OpenVMS grants temporary priority boosts to normal processes under certain conditions, including the completion of an I/O operation. This allows the process to resume operation sooner and results in smoother overall system performance. These priority boosts are taken away once the process has been current for a short time.
There exists a range of real-time priorities, from 16 through 31, which follows different scheduling rules. Specifically, real-time processes stay current until preempted by a higher-priority process or until they give up the CPU. Real-time priorities are intended for specific purposes only; do not assign a priority in this range to a process without a specific reason. Misuse of the real-time priority range can render the system unresponsive under certain conditions.
Note | OpenVMS has internal data structures in place to support 64 priority levels, as required by certain Open Systems standards. Currently, only 32 levels are used. |
At this point, the reader may wonder whether a process executing at one priority (say, 4) can permanently prevent a process at a lower priority (say, 2) from executing. Normally, the answer would be yes, but OpenVMS ensures that all processes receive a small amount of CPU service, regardless of their priority. This prevents a low-priority process from locking a systemwide resource and then becoming starved for CPU service. Otherwise, the low-priority process might never be able to release an important resource, adversely affecting other processes.